From david.holmes at oracle.com  Sun Sep  1 22:30:52 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Sep 2019 08:30:52 +1000
Subject: [PATCH] Darwin, option to monitor anonymous pages
In-Reply-To: <CA+XhMqza2TDxMQ4qZGYXm6gY01r+v2Fefn=No2xYaa-1wScpFg@mail.gmail.com>
References: <CA+XhMqza2TDxMQ4qZGYXm6gY01r+v2Fefn=No2xYaa-1wScpFg@mail.gmail.com>
Message-ID: <f3abb929-fbfa-6851-89e1-b11b9bbf7ae5@oracle.com>

Hi David,

On 1/09/2019 6:19 am, David CARLIER wrote:
> Hi
> 
> Here a little patch proposal to be able to monitor anonymous pages
> with tools like mmap

This patch add a product flag which requires additional processes to be 
followed. Changes to product flags require a CSR request [1] to be filed 
and approved. Without an author/committer to actively work with you to 
get these patches through the process they will likely just languish on 
the mailing list.

David H.

[1] https://wiki.openjdk.java.net/display/csr/Main

> Kind regards.
> 
> # HG changeset patch
> # User David Carlier <devnexen at gmail.com>
> # Date 1567278245 -3600
> #      Sat Aug 31 20:04:05 2019 +0100
> # Node ID 7c566025b2e224b241704ec3a3f2fb8c70167c48
> # Parent  1262b3ddd7e4f010bf81f2564bf86e7e2c00467a
> Darwin, option to monitor anonymous pages
> 
> new flag AnonMapId, from 240 up to 255
> to follow up Apple recommendations and flexibility
> to avoid collisions with increasing code using it.
> 
> diff -r 1262b3ddd7e4 -r 7c566025b2e2 src/hotspot/os/bsd/globals_bsd.hpp
> --- a/src/hotspot/os/bsd/globals_bsd.hpp Sat Aug 31 09:18:40 2019 -0700
> +++ b/src/hotspot/os/bsd/globals_bsd.hpp Sat Aug 31 20:04:05 2019 +0100
> @@ -46,6 +46,7 @@
>     /*  overridden in Arguments::parse_each_vm_init_arg.            */
>            \
>     product(bool, UseBsdPosixThreadCPUClocks, true,
>            \
>             "enable fast Bsd Posix clocks where available")
>            \
> +  product(intx, AnonMapId, 240, "set anonymous page tag ID")
>            \
> 
>   //
>   // Defines Bsd-specific default values. The flags are available on all
> diff -r 1262b3ddd7e4 -r 7c566025b2e2 src/hotspot/os/bsd/os_bsd.cpp
> --- a/src/hotspot/os/bsd/os_bsd.cpp Sat Aug 31 09:18:40 2019 -0700
> +++ b/src/hotspot/os/bsd/os_bsd.cpp Sat Aug 31 20:04:05 2019 +0100
> @@ -104,6 +104,7 @@
> 
>   #ifdef __APPLE__
>     #include <mach-o/dyld.h>
> +  #include <mach/vm_statistics.h>
>   #endif
> 
>   #ifndef MAP_ANONYMOUS
> @@ -2066,18 +2067,26 @@
>   static char* anon_mmap(char* requested_addr, size_t bytes, bool fixed) {
>     char * addr;
>     int flags;
> +  int fd;
> 
>     flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS;
> +  fd = -1;
>     if (fixed) {
>       assert((uintptr_t)requested_addr % os::Bsd::page_size() == 0,
> "unaligned address");
>       flags |= MAP_FIXED;
>     }
> +#ifdef __APPLE__
> +  // Apple guarantees free IDs from 240 up to 255
> +  // for userland applications.
> +  if (AnonMapId >= 240 && AnonMapId < 255)
> +    fd = VM_MAKE_TAG(AnonMapId);
> +#endif
> 
>     // Map reserved/uncommitted pages PROT_NONE so we fail early if we
>     // touch an uncommitted page. Otherwise, the read/write might
>     // succeed if we have enough swap space to back the physical page.
>     addr = (char*)::mmap(requested_addr, bytes, PROT_NONE,
> -                       flags, -1, 0);
> +                       flags, fd, 0);
> 
>     return addr == MAP_FAILED ? NULL : addr;
>   }
> 

From leo.korinth at oracle.com  Mon Sep  2 12:23:15 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Mon, 2 Sep 2019 14:23:15 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
Message-ID: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>

Hi!

After I got caught doing an unnecessary check on the return value of 
NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to 
do a cleanup in the sources so that others would not fall into this 
trap. This is the result.

I have removed some places where the VM will be shut down after 
NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does 
instead exit). I have also removed lots of unnecessary casts, that might 
hide bugs.

There are /numerous/ buggy usage that I have NOT fixed. Those are bugs 
that ought to be fixed, but they are not in the gc folder, and I am 
unsure about the best solution (the do not just directly exit the VM). I 
have created a BUG to track them 
(https://bugs.openjdk.java.net/browse/JDK-8230395), and I will leave 
them for others to solve.

I have changed some code paths that I can not test (AIX for example) so 
it would be nice if someone could verify it works there.

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

Webrev:
http://cr.openjdk.java.net/~lkorinth/8227168/

Testing:
mach5 tier1-3 (solaris, linux, windows, mac)

Thanks,
Leo

From leo.korinth at oracle.com  Mon Sep  2 13:06:13 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Mon, 2 Sep 2019 15:06:13 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
Message-ID: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>

Hi!

This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is 
unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a 
follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.

deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does 
(in addition to NULL the pointer) also set a counter to zero. Although 
my change "looks" correct, I tried follow the usage of 
deallocate_counters(), and could not find a call site. Should I create a 
bug on this, or am I missing something here?

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

Webrev:
http://cr.openjdk.java.net/~lkorinth/8230398

Testing:
mach5 tier1-3

Thanks,
Leo

From thomas.schatzl at oracle.com  Mon Sep  2 13:21:13 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 02 Sep 2019 15:21:13 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
Message-ID: <f1e7eab4941158f5b4660ee36f009d6eb0324f92.camel@oracle.com>

Hi,

On Mon, 2019-09-02 at 14:23 +0200, Leo Korinth wrote:
> Hi!
> 
> After I got caught doing an unnecessary check on the return value of 
> NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good
> to do a cleanup in the sources so that others would not fall into
> this trap. This is the result.
> 
> I have removed some places where the VM will be shut down after 
> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does 
> instead exit). I have also removed lots of unnecessary casts, that
> might hide bugs.
> 
> 
[...]
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8227168
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8227168/
> 
> Testing:
> mach5 tier1-3 (solaris, linux, windows, mac)

  looks good. Thanks.

Thomas



From leo.korinth at oracle.com  Mon Sep  2 15:35:20 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Mon, 2 Sep 2019 17:35:20 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <f1e7eab4941158f5b4660ee36f009d6eb0324f92.camel@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <f1e7eab4941158f5b4660ee36f009d6eb0324f92.camel@oracle.com>
Message-ID: <b2d21429-67af-6615-c6aa-5a1124d1bbe7@oracle.com>

On 02/09/2019 15:21, Thomas Schatzl wrote:
> Hi,
> 
> On Mon, 2019-09-02 at 14:23 +0200, Leo Korinth wrote:
>> Hi!
>>
>> After I got caught doing an unnecessary check on the return value of
>> NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good
>> to do a cleanup in the sources so that others would not fall into
>> this trap. This is the result.
>>
>> I have removed some places where the VM will be shut down after
>> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does
>> instead exit). I have also removed lots of unnecessary casts, that
>> might hide bugs.
>>
>>
> [...]
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8227168
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8227168/
>>
>> Testing:
>> mach5 tier1-3 (solaris, linux, windows, mac)
> 
>    looks good. Thanks.
Thanks for the review!
/Leo
> 
> Thomas
> 
> 

From kim.barrett at oracle.com  Mon Sep  2 18:52:54 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 2 Sep 2019 14:52:54 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
Message-ID: <5C8EF639-DE44-42A1-B3C3-E02F752D465B@oracle.com>

> On Sep 2, 2019, at 8:23 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
> 
> Hi!
> 
> After I got caught doing an unnecessary check on the return value of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to do a cleanup in the sources so that others would not fall into this trap. This is the result.
> 
> I have removed some places where the VM will be shut down after NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does instead exit). I have also removed lots of unnecessary casts, that might hide bugs.
> 
> There are /numerous/ buggy usage that I have NOT fixed. Those are bugs that ought to be fixed, but they are not in the gc folder, and I am unsure about the best solution (the do not just directly exit the VM). I have created a BUG to track them (https://bugs.openjdk.java.net/browse/JDK-8230395), and I will leave them for others to solve.
> 
> I have changed some code paths that I can not test (AIX for example) so it would be nice if someone could verify it works there.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8227168
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8227168/
> 
> Testing:
> mach5 tier1-3 (solaris, linux, windows, mac)
> 
> Thanks,
> Leo

Looks good.  Yay for unnecessary cast removals!


From kim.barrett at oracle.com  Mon Sep  2 20:38:32 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 2 Sep 2019 16:38:32 -0400
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
Message-ID: <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>

> On Sep 2, 2019, at 9:06 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
> 
> Hi!
> 
> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
> 
> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does (in addition to NULL the pointer) also set a counter to zero. Although my change "looks" correct, I tried follow the usage of deallocate_counters(), and could not find a call site. Should I create a bug on this, or am I missing something here?

Your modification to deallocate_counters looks fine.  I don't think
you are missing anything, I think it's not called.  That does look
like it might be a (pre-existing) bug.  Maybe they are immortal?  But
that isn't obvious from a quick skim.

> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8230398
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8230398
> 
> Testing:
> mach5 tier1-3
> 
> Thanks,
> Leo

------------------------------------------------------------------------------

[pre-existing]
There are some destructors that are unnecessarily nulling out members
after deleting their values, such as here:

src/hotspot/share/classfile/classLoader.cpp
 387   FREE_C_HEAP_ARRAY(const char, _name);
 388   _name = NULL;

src/hotspot/share/gc/g1/sparsePRT.cpp
106 RSHashTable::~RSHashTable() {

src/hotspot/share/gc/shared/cardTableRS.cpp
626 CardTableRS::~CardTableRS() {

src/hotspot/share/runtime/thread.cpp
1330 NamedThread::~NamedThread() {

Your call whether you want to do anything about these with this change.

------------------------------------------------------------------------------

Other than that, looks good.  I don't need another webrev if you
decide to remove the above assignments to NULL near code you were
already changing.  A more extensive pass for such should perhaps be a
separate change.


From david.holmes at oracle.com  Mon Sep  2 21:59:19 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Sep 2019 07:59:19 +1000
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
Message-ID: <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>

Hi Leo,

On 2/09/2019 10:23 pm, Leo Korinth wrote:
> Hi!
> 
> After I got caught doing an unnecessary check on the return value of 
> NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to 
> do a cleanup in the sources so that others would not fall into this 
> trap. This is the result.
> 
> I have removed some places where the VM will be shut down after 
> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does 
> instead exit). I have also removed lots of unnecessary casts, that might 
> hide bugs.

Those changes all seem fine, as are the perfMemory changes.

My only issue is with the places where you can changed allocation of a 
NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still freed 
with FREE_C_HEAP_ARRAY which looks odd even though correct (in that it's 
all os::free under the covers anyway). I'm not sure this change is worth 
the potential confusion it may cause.

> There are /numerous/ buggy usage that I have NOT fixed. Those are bugs 
> that ought to be fixed, but they are not in the gc folder, and I am 
> unsure about the best solution (the do not just directly exit the VM). I 
> have created a BUG to track them 
> (https://bugs.openjdk.java.net/browse/JDK-8230395), and I will leave 
> them for others to solve.

Okay.

Thanks,
David
-----

> I have changed some code paths that I can not test (AIX for example) so 
> it would be nice if someone could verify it works there.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8227168
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8227168/
> 
> Testing:
> mach5 tier1-3 (solaris, linux, windows, mac)
> 
> Thanks,
> Leo

From david.holmes at oracle.com  Mon Sep  2 22:09:57 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Sep 2019 08:09:57 +1000
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
Message-ID: <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>

Hi Leo,

On 2/09/2019 11:06 pm, Leo Korinth wrote:
> Hi!
> 
> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is 
> unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a 
> follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.

I don't see such a NULL check except in debug builds:

#define FREE_C_HEAP_ARRAY(type, old) \
   FreeHeap((char*)(old))

void FreeHeap(void* p) {
   os::free(p);
}

void  os::free(void *memblock) {
   NOT_PRODUCT(inc_stat_counter(&num_frees, 1));
#ifdef ASSERT
   if (memblock == NULL) return;
   if ((intptr_t)memblock == (intptr_t)MallocCatchPtr) {
     log_warning(malloc, free)("os::free caught " PTR_FORMAT, 
p2i(memblock));
     breakpoint();
   }
   void* membase = MemTracker::record_free(memblock);
   verify_memory(membase);

   GuardedMemory guarded(membase);
   size_t size = guarded.get_user_size();
   inc_stat_counter(&free_bytes, size);
   membase = guarded.release_for_freeing();
   ::free(membase);
#else
   void* membase = MemTracker::record_free(memblock);
   ::free(membase);
#endif
}

Also this would now count NULL frees (which seems a bug in itself).

> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does 
> (in addition to NULL the pointer) also set a counter to zero. Although 
> my change "looks" correct, I tried follow the usage of 
> deallocate_counters(), and could not find a call site. Should I create a 
> bug on this, or am I missing something here?

It looks like dead code. People often write clean symmetrical allocation 
and freeing code, but the VM doesn't actually free a lot of stuff at 
termination.

> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8230398
> 
> Webrev:
> http://cr.openjdk.java.net/~lkorinth/8230398
> 
> Testing:
> mach5 tier1-3
> 
> Thanks,
> Leo

From kim.barrett at oracle.com  Mon Sep  2 23:41:55 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 2 Sep 2019 19:41:55 -0400
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>
Message-ID: <EB136626-8386-4AC2-BFD1-10C29990B56C@oracle.com>

> On Sep 2, 2019, at 6:09 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Leo,
> 
> On 2/09/2019 11:06 pm, Leo Korinth wrote:
>> Hi!
>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
> 
> I don't see such a NULL check except in debug builds:
> 
> #define FREE_C_HEAP_ARRAY(type, old) \
>  FreeHeap((char*)(old))
> 
> void FreeHeap(void* p) {
>  os::free(p);
> }
> 
> void  os::free(void *memblock) {
>  NOT_PRODUCT(inc_stat_counter(&num_frees, 1));
> #ifdef ASSERT
>  if (memblock == NULL) return;
>  if ((intptr_t)memblock == (intptr_t)MallocCatchPtr) {
>    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>    breakpoint();
>  }
>  void* membase = MemTracker::record_free(memblock);
>  verify_memory(membase);
> 
>  GuardedMemory guarded(membase);
>  size_t size = guarded.get_user_size();
>  inc_stat_counter(&free_bytes, size);
>  membase = guarded.release_for_freeing();
>  ::free(membase);
> #else
>  void* membase = MemTracker::record_free(memblock);
>  ::free(membase);
> #endif
> }

os::free is like ::free; if the argument is NULL then no operation is
performed. Any other behavior seems like it would be surprising. And I
suspect there is code that assumes that. This change is just cleaning
up code that has a redundant check.

In the !ASSERT case one has to do a bit more call chain following to
find the NULL check:

MemTracker::record_free(void* memblock)
  => MallocTracker::record_free(void* memblock)
  => if (MemTracker::tracking_level() == NMT_off ||
         memblock == NULL) {      // <<<< NULL check is here
       return memblock;
     }

The returned value is passed to ::free.

It might be more obvious if os::free had an up-front NULL check, and
MallocTracker could assume (assert) the memblock is non-NULL.  But
such a NULL check would be redundant when NMT_off.


> 
> Also this would now count NULL frees (which seems a bug in itself).

Depends on whether it is counting the calls to free, or counting the number of allocated
blocks that were freed.

>> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does (in addition to NULL the pointer) also set a counter to zero. Although my change "looks" correct, I tried follow the usage of deallocate_counters(), and could not find a call site. Should I create a bug on this, or am I missing something here?
> 
> It looks like dead code. People often write clean symmetrical allocation and freeing code, but the VM doesn't actually free a lot of stuff at termination.

It?s a file-scoped function; some compilers (like gcc with appropriate options) would warn
about it being defined but unused.

Hm, but the indentation didn?t get updated when the surrounding if was removed.

> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8230398
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8230398
>> Testing:
>> mach5 tier1-3
>> Thanks,
>> Leo



From kim.barrett at oracle.com  Mon Sep  2 23:46:29 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 2 Sep 2019 19:46:29 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
Message-ID: <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>

> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>> Hi!
>> After I got caught doing an unnecessary check on the return value of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to do a cleanup in the sources so that others would not fall into this trap. This is the result.
>> I have removed some places where the VM will be shut down after NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does instead exit). I have also removed lots of unnecessary casts, that might hide bugs.
> 
> Those changes all seem fine, as are the perfMemory changes.
> 
> My only issue is with the places where you can changed allocation of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still freed with FREE_C_HEAP_ARRAY which looks odd even though correct (in that it's all os::free under the covers anyway). I'm not sure this change is worth the potential confusion it may cause.

I noticed that too, and then forgot about it.  I agree that?s not right.  I think those places
should be changed to use FREE_C_HEAP_OBJ for the deallocation.


From david.holmes at oracle.com  Tue Sep  3 00:37:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Sep 2019 10:37:50 +1000
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <EB136626-8386-4AC2-BFD1-10C29990B56C@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>
 <EB136626-8386-4AC2-BFD1-10C29990B56C@oracle.com>
Message-ID: <3fd2cf89-3594-6be6-8edd-380f20f56e0a@oracle.com>

On 3/09/2019 9:41 am, Kim Barrett wrote:
>> On Sep 2, 2019, at 6:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Leo,
>>
>> On 2/09/2019 11:06 pm, Leo Korinth wrote:
>>> Hi!
>>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>
>> I don't see such a NULL check except in debug builds:
>>
>> #define FREE_C_HEAP_ARRAY(type, old) \
>>   FreeHeap((char*)(old))
>>
>> void FreeHeap(void* p) {
>>   os::free(p);
>> }
>>
>> void  os::free(void *memblock) {
>>   NOT_PRODUCT(inc_stat_counter(&num_frees, 1));
>> #ifdef ASSERT
>>   if (memblock == NULL) return;
>>   if ((intptr_t)memblock == (intptr_t)MallocCatchPtr) {
>>     log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>>     breakpoint();
>>   }
>>   void* membase = MemTracker::record_free(memblock);
>>   verify_memory(membase);
>>
>>   GuardedMemory guarded(membase);
>>   size_t size = guarded.get_user_size();
>>   inc_stat_counter(&free_bytes, size);
>>   membase = guarded.release_for_freeing();
>>   ::free(membase);
>> #else
>>   void* membase = MemTracker::record_free(memblock);
>>   ::free(membase);
>> #endif
>> }
> 
> os::free is like ::free; if the argument is NULL then no operation is
> performed. Any other behavior seems like it would be surprising. And I
> suspect there is code that assumes that. This change is just cleaning
> up code that has a redundant check.
> In the !ASSERT case one has to do a bit more call chain following to
> find the NULL check:
> 
> MemTracker::record_free(void* memblock)
>    => MallocTracker::record_free(void* memblock)
>    => if (MemTracker::tracking_level() == NMT_off ||
>           memblock == NULL) {      // <<<< NULL check is here
>         return memblock;
>       }
> 
> The returned value is passed to ::free.
> 
> It might be more obvious if os::free had an up-front NULL check, and
> MallocTracker could assume (assert) the memblock is non-NULL.  But
> such a NULL check would be redundant when NMT_off.

I understand this is all functionally correct. But I don't see that it 
is necessarily a bad thing to do these "redundant" NULL checks up front 
as an optimisation rather than relying on the called code to eventually 
notice there is nothing to do. And it's not obvious that its okay to use 
FREE_C_HEAP_ARRAY with a NULL value, so you can understand why people 
add the check.

>>
>> Also this would now count NULL frees (which seems a bug in itself).
> 
> Depends on whether it is counting the calls to free, or counting the number of allocated
> blocks that were freed.

Whichever it is this change results in a change to that behaviour. It's 
probably harmless, but its a change.

Cheers,
David

>>> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does (in addition to NULL the pointer) also set a counter to zero. Although my change "looks" correct, I tried follow the usage of deallocate_counters(), and could not find a call site. Should I create a bug on this, or am I missing something here?
>>
>> It looks like dead code. People often write clean symmetrical allocation and freeing code, but the VM doesn't actually free a lot of stuff at termination.
> 
> It?s a file-scoped function; some compilers (like gcc with appropriate options) would warn
> about it being defined but unused.
> 
> Hm, but the indentation didn?t get updated when the surrounding if was removed.
> 
>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8230398
>>> Webrev:
>>> http://cr.openjdk.java.net/~lkorinth/8230398
>>> Testing:
>>> mach5 tier1-3
>>> Thanks,
>>> Leo
> 
> 

From kim.barrett at oracle.com  Tue Sep  3 03:05:10 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 2 Sep 2019 23:05:10 -0400
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <3fd2cf89-3594-6be6-8edd-380f20f56e0a@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>
 <EB136626-8386-4AC2-BFD1-10C29990B56C@oracle.com>
 <3fd2cf89-3594-6be6-8edd-380f20f56e0a@oracle.com>
Message-ID: <3ADB2C9F-5912-4CDC-80C2-64B39C1A7925@oracle.com>

> On Sep 2, 2019, at 8:37 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 3/09/2019 9:41 am, Kim Barrett wrote:
>>> On Sep 2, 2019, at 6:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Hi Leo,
>>> 
>>> On 2/09/2019 11:06 pm, Leo Korinth wrote:
>>>> Hi!
>>>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>> 
>>> I don't see such a NULL check except in debug builds:
>>> 
>>> #define FREE_C_HEAP_ARRAY(type, old) \
>>>  FreeHeap((char*)(old))
>>> 
>>> void FreeHeap(void* p) {
>>>  os::free(p);
>>> }
>>> 
>>> void  os::free(void *memblock) {
>>>  NOT_PRODUCT(inc_stat_counter(&num_frees, 1));
>>> #ifdef ASSERT
>>>  if (memblock == NULL) return;
>>>  if ((intptr_t)memblock == (intptr_t)MallocCatchPtr) {
>>>    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>>>    breakpoint();
>>>  }
>>>  void* membase = MemTracker::record_free(memblock);
>>>  verify_memory(membase);
>>> 
>>>  GuardedMemory guarded(membase);
>>>  size_t size = guarded.get_user_size();
>>>  inc_stat_counter(&free_bytes, size);
>>>  membase = guarded.release_for_freeing();
>>>  ::free(membase);
>>> #else
>>>  void* membase = MemTracker::record_free(memblock);
>>>  ::free(membase);
>>> #endif
>>> }
>> os::free is like ::free; if the argument is NULL then no operation is
>> performed. Any other behavior seems like it would be surprising. And I
>> suspect there is code that assumes that. This change is just cleaning
>> up code that has a redundant check.
>> In the !ASSERT case one has to do a bit more call chain following to
>> find the NULL check:
>> MemTracker::record_free(void* memblock)
>>   => MallocTracker::record_free(void* memblock)
>>   => if (MemTracker::tracking_level() == NMT_off ||
>>          memblock == NULL) {      // <<<< NULL check is here
>>        return memblock;
>>      }
>> The returned value is passed to ::free.
>> It might be more obvious if os::free had an up-front NULL check, and
>> MallocTracker could assume (assert) the memblock is non-NULL.  But
>> such a NULL check would be redundant when NMT_off.
> 
> I understand this is all functionally correct. But I don't see that it is necessarily a bad thing to do these "redundant" NULL checks up front as an optimisation rather than relying on the called code to eventually notice there is nothing to do.

Except it's not an optimization.  The value will usually (nearly(?)
always) be non-NULL, making the NULL pre-check is a waste of time and
code.  Indeed, in many cases a NULL value is simply not possible; the
value is the result of a NEW_C_HEAP_ARRAY call that would have
terminated the application rather than returning NULL.

>  And it's not obvious that its okay to use FREE_C_HEAP_ARRAY with a NULL value, so you can understand why people add the check.

As usual, there isn?t any documentation of the intended behavior; one must
read the code.  That?s a separate problem.

>>> Also this would now count NULL frees (which seems a bug in itself).
>> Depends on whether it is counting the calls to free, or counting the number of allocated
>> blocks that were freed.
> 
> Whichever it is this change results in a change to that behaviour. It's probably harmless, but its a change.

Looks harmless to me, especially since it doesn?t affect product code.
The only configuration that is being changed is the ?optimize? build that various
folks periodically suggest killing off.



From david.holmes at oracle.com  Tue Sep  3 03:31:14 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Sep 2019 13:31:14 +1000
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <3ADB2C9F-5912-4CDC-80C2-64B39C1A7925@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <eb1f833e-75e5-18a1-f176-6b76342d8b28@oracle.com>
 <EB136626-8386-4AC2-BFD1-10C29990B56C@oracle.com>
 <3fd2cf89-3594-6be6-8edd-380f20f56e0a@oracle.com>
 <3ADB2C9F-5912-4CDC-80C2-64B39C1A7925@oracle.com>
Message-ID: <f8aa2460-2ebb-47a6-9087-78ed842db8d5@oracle.com>

Okay - no point belabouring this. The code is functionally fine.

The os::free/malloc counters seem to be only used for reporting when 
memory verification fails and they're maintained in a buggy way already.

Thanks,
David

On 3/09/2019 1:05 pm, Kim Barrett wrote:
>> On Sep 2, 2019, at 8:37 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 3/09/2019 9:41 am, Kim Barrett wrote:
>>>> On Sep 2, 2019, at 6:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Leo,
>>>>
>>>> On 2/09/2019 11:06 pm, Leo Korinth wrote:
>>>>> Hi!
>>>>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>>>
>>>> I don't see such a NULL check except in debug builds:
>>>>
>>>> #define FREE_C_HEAP_ARRAY(type, old) \
>>>>   FreeHeap((char*)(old))
>>>>
>>>> void FreeHeap(void* p) {
>>>>   os::free(p);
>>>> }
>>>>
>>>> void  os::free(void *memblock) {
>>>>   NOT_PRODUCT(inc_stat_counter(&num_frees, 1));
>>>> #ifdef ASSERT
>>>>   if (memblock == NULL) return;
>>>>   if ((intptr_t)memblock == (intptr_t)MallocCatchPtr) {
>>>>     log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>>>>     breakpoint();
>>>>   }
>>>>   void* membase = MemTracker::record_free(memblock);
>>>>   verify_memory(membase);
>>>>
>>>>   GuardedMemory guarded(membase);
>>>>   size_t size = guarded.get_user_size();
>>>>   inc_stat_counter(&free_bytes, size);
>>>>   membase = guarded.release_for_freeing();
>>>>   ::free(membase);
>>>> #else
>>>>   void* membase = MemTracker::record_free(memblock);
>>>>   ::free(membase);
>>>> #endif
>>>> }
>>> os::free is like ::free; if the argument is NULL then no operation is
>>> performed. Any other behavior seems like it would be surprising. And I
>>> suspect there is code that assumes that. This change is just cleaning
>>> up code that has a redundant check.
>>> In the !ASSERT case one has to do a bit more call chain following to
>>> find the NULL check:
>>> MemTracker::record_free(void* memblock)
>>>    => MallocTracker::record_free(void* memblock)
>>>    => if (MemTracker::tracking_level() == NMT_off ||
>>>           memblock == NULL) {      // <<<< NULL check is here
>>>         return memblock;
>>>       }
>>> The returned value is passed to ::free.
>>> It might be more obvious if os::free had an up-front NULL check, and
>>> MallocTracker could assume (assert) the memblock is non-NULL.  But
>>> such a NULL check would be redundant when NMT_off.
>>
>> I understand this is all functionally correct. But I don't see that it is necessarily a bad thing to do these "redundant" NULL checks up front as an optimisation rather than relying on the called code to eventually notice there is nothing to do.
> 
> Except it's not an optimization.  The value will usually (nearly(?)
> always) be non-NULL, making the NULL pre-check is a waste of time and
> code.  Indeed, in many cases a NULL value is simply not possible; the
> value is the result of a NEW_C_HEAP_ARRAY call that would have
> terminated the application rather than returning NULL.
> 
>>   And it's not obvious that its okay to use FREE_C_HEAP_ARRAY with a NULL value, so you can understand why people add the check.
> 
> As usual, there isn?t any documentation of the intended behavior; one must
> read the code.  That?s a separate problem.
> 
>>>> Also this would now count NULL frees (which seems a bug in itself).
>>> Depends on whether it is counting the calls to free, or counting the number of allocated
>>> blocks that were freed.
>>
>> Whichever it is this change results in a change to that behaviour. It's probably harmless, but its a change.
> 
> Looks harmless to me, especially since it doesn?t affect product code.
> The only configuration that is being changed is the ?optimize? build that various
> folks periodically suggest killing off.
> 
> 

From matthias.baesken at sap.com  Tue Sep  3 07:42:55 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 3 Sep 2019 07:42:55 +0000
Subject: RFR: 8230466: check malloc/calloc results in jdk.hotspot.agent
Message-ID: <AM6PR02MB50787A456E9A8F196330817693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello, please review the following small fix .

In   jdk.hotspot.agent  native code (linux / macosx)   we miss to check the  result of malloc/calloc a few times .
This should be  adjusted.
Additionally  I added initialization  to the symtab  array  in  symtab.c   (by calling memset  to make sure we have a defined state )  .



One question (was not really sure about this one so I did not change it so far) :

http://cr.openjdk.java.net/~mbaesken/webrevs/8230466.0/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.frames.html

359 void destroy_symtab(symtab_t* symtab) {
360   if (!symtab) return;
361   free(symtab->strs);
362   free(symtab->symbols);
363   free(symtab);
364 }



Here we miss to close   symtab->hash_table   (opened by  dbopen) ,  is it needed  (haven't  used dbopen much - maybe someone can comment on this)?


bug/webrev :

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

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


Thanks and best regards, Matthias

From christoph.langer at sap.com  Tue Sep  3 08:29:35 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Sep 2019 08:29:35 +0000
Subject: RFR [XS] : 8229182:
 runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
In-Reply-To: <AM6PR02MB5078ED87084D559FCD496B2F93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078C0576ACB5B521C80F3BA93D40@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <AM6PR02MB507824542AC788AE9FC347CD93AF0@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com>
 <AM6PR02MB50787A2AD53BD6F812E2380793AF0@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com>
 <AM6PR02MB50783B0954045D73EC22556793A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com>
 <AM6PR02MB5078B8DEA9DF9ED2202F3E2093A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com>
 <AM6PR02MB507845915866850984AF95B993A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com>
 <AM6PR02MB5078435C165407C3BA3AA63893A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com>
 <FED40943-2CC8-4FBB-AB8D-B14FCAB965DB@oracle.com>
 <5D656531.6080204@oracle.com> <5D65988B.5040807@oracle.com>
 <AM6PR02MB5078ED87084D559FCD496B2F93BD0@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB519286C196E63584AA1A4D1A8AB90@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Matthias,

overall the patch looks good to me (and proves to solve the test issue in our nightlies).

I have some minor nits/room for cleanup:

test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java:
- Copyright year should be updated
- Line 38, initialization of ArrayList: This could be written as new ArrayList< >();, e.g.
public ArrayList<String> javaOptsAppended = new ArrayList< >();
Maybe you can update the initializations in line 34, 36 and 40 as well.

test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java (as you are touching it):
line 43 " import jdk.test.lib.process.ProcessTools;" can be removed
line 48 " private static final String FS = File.separator;" can be removed

Don't need to see a new webrev for that.

Thanks & Best regards
Christoph

> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> Baesken, Matthias
> Sent: Freitag, 30. August 2019 15:44
> To: Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com>
> Cc: hotspot-dev at openjdk.java.net
> Subject: RE: RFR [XS] : 8229182:
> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12
> 
> Hello ,  here is a  new revision  that  retains  the javaTest options and  just
> resets Xmx .
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.4/
> 
> I checked your proposal to use
> jdk.test.lib.Utils.getFilteredTestJavaOpts(String...  filters)   ; unfortunately  it
> does not really  do what I want .
> This  returns me a copy  of the  filtered TestJavaOpts .
> 
> But in DockerTestUtils.java   buildJavaCommand   we   still use the  real
> (unfiltered) options , unless  we set    opts.appendTestJavaOptions    to false
> .
> And I think it was stated  in the review  that  it isn?t  wanted to  set
> opts.appendTestJavaOptions    to false  (because this  would  remove    not
> only  the unwanted  Xmx  in our case but more options that might be needed
> ).
> 
> So    8229182.4   allows   to  intentionally  set   another Xmx   AFTER   what
> Utils.getTestJavaOpts   ,  this is what we want in this test  and it should be
> compatible   for other users  of    DockerTestUtils.java  .
> 
> Best regards, Matthias
> 
> 
> 
> > -----Original Message-----
> > From: Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com>
> > Sent: Dienstag, 27. August 2019 22:55
> > To: Baesken, Matthias <matthias.baesken at sap.com>
> > Cc: Bob Vandette <bob.vandette at oracle.com>; hotspot-
> > dev at openjdk.java.net
> > Subject: Re: RFR [XS] : 8229182:
> > runtime/containers/docker/TestMemoryAwareness.java test fails on
> SLES12
> >
> > FYI: you could use jdk.test.lib.Utils.getFilteredTestJavaOpts(String...
> > filters) for this purpose.
> >
> > On 8/27/19, 10:15 AM, Mikhailo Seledtsov wrote:
> > > I agree with Bob. It seems this is exactly what we wish in this case:
> > > filter out/eliminate some options that interfere with the test, while
> > > retaining other options and passing them to the JVM running inside a
> > > container.
> > >
> > >
> > > Thank you,
> > > Misha
> > >
> > > On 8/27/19, 8:42 AM, Bob Vandette wrote:
> > >> This is an isolated problem and I don?t like the idea of adding a new
> > >> option just for this case.
> > >>
> > >> What if we parse the options and eliminated the general -Xmx option
> > >> if one was specified
> > >> by the test?  After all, this is the intention of adding a test
> > >> specific heap limit.
> > >>
> > >> Bob.
> > >>
> > >>
> > >>
> > >>> On Aug 27, 2019, at 10:33 AM, Severin
> Gehwolf<sgehwolf at redhat.com>
> > >>> wrote:
> > >>>
> > >>> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote:
> > >>>> Hello  ,   my suggestions was " appendJavaOpts "   :
> > >>>>
> > >>> OK, got it now. Looking at the webrev this wasn't clear as it didn't do
> > >>> that.
> > >>>
> > >>>>      In case we want to be safe,  I suggest to
> > >>>> add  an  additional  method   " appendJavaOpts "
> > >>>>
> > >>>>      opts.appendJavaOpts("-Xmx" + javaHeapSize);
> > >>>>
> > >>>>      to DockerRunOptions ;  appendJavaOpts   would append  the
> > >>>> options  after  the  testJavaOpts    (so Xmx can be overwritten ).
> > >>>>
> > >>>> But if  overrideJavaOpts    is preferred  that fine with me too ...
> > >>> I'd prefer a more telling name than "append". I'd ask myself when
> > >>> trying to use it: Does it append to regular java options? How is it
> > >>> different from addJavaOpts()? You get the idea. I'd prefer
> > >>> overrideJavaOpts for that reason.
> > >>>
> > >>> Perhaps addOverrideOpts()? Either way, the javadoc should make it
> > clear
> > >>> what adding options there means.
> > >>>
> > >>> Thanks,
> > >>> Severin
> > >>>
> > >>>> Best regards, Matthias
> > >>>>
> > >>>>
> > >>>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote:
> > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/
> > >>>>> OK, so, in summary, the constraints are as follows:
> > >>>>>
> > >>>>> * We don't want to turn of appending global test java options as
> > >>>>> these
> > >>>>>    could possibly contain local options to a specific test
> > >>>>> environment.
> > >>>>>    It would be a surprise if docker tests wouldn't have them.
> > >>>>> * Just setting Java options is not enough as the intention is to
> > >>>>> set
> > >>>>>    them for the Docker test, but could potentially be overridden by
> > >>>>>    global test options (this issue).
> > >>>>>
> > >>>>> Given we'd like to keep that general design, maybe it would make
> > >>>>> sense
> > >>>>> to create a 3'rd, separate set of flags, neither java options nor
> > >>>>> test
> > >>>>> options would manage to override. Call it "overrideJavaOpts" or
> > >>>>> some
> > >>>>> such. At least that would make it clear that these options if set
> > >>>>> have
> > >>>>> the final say.
> > >>>>>
> > >>>>> Thoughts?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Severin

From leo.korinth at oracle.com  Tue Sep  3 16:12:45 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 3 Sep 2019 18:12:45 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
Message-ID: <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>

On 03/09/2019 01:46, Kim Barrett wrote:
>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>> Hi!
>>> After I got caught doing an unnecessary check on the return value of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to do a cleanup in the sources so that others would not fall into this trap. This is the result.
>>> I have removed some places where the VM will be shut down after NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does instead exit). I have also removed lots of unnecessary casts, that might hide bugs.
>>
>> Those changes all seem fine, as are the perfMemory changes.
>>
>> My only issue is with the places where you can changed allocation of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still freed with FREE_C_HEAP_ARRAY which looks odd even though correct (in that it's all os::free under the covers anyway). I'm not sure this change is worth the potential confusion it may cause.
> 
> I noticed that too, and then forgot about it.  I agree that?s not right.  I think those places
> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
> 

Thank you for finding this. I actually considered implementing the macro 
FREE_C_HEAP_OBJ as I could not find it. Now I can not understand how I 
could /miss/ it, though I guess I was looking for a macro with the same 
signature as FREE_C_HEAP_ARRAY (one taking the type as argument) :-(

As a consequence I also deleted some outdated help text:

- //   NEW_RESOURCE_ARRAY(type, size)
- //   NEW_RESOURCE_OBJ(type)
- //   NEW_C_HEAP_ARRAY(type, size)
- //   NEW_C_HEAP_OBJ(type, memflags)
- //   FREE_C_HEAP_ARRAY(type, old)
- //   FREE_C_HEAP_OBJ(objname, type, memflags)
- //   char* AllocateHeap(size_t size, const char* name);
- //   void  FreeHeap(void* p);

I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to 
also be an array type when allocated in another place.

Incremental:
http://cr.openjdk.java.net/~lkorinth/8227168/00_01/

Full:
http://cr.openjdk.java.net/~lkorinth/8227168/01/

rerunning tests...

Thanks, Leo

From coleen.phillimore at oracle.com  Tue Sep  3 17:19:36 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Tue, 3 Sep 2019 13:19:36 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
Message-ID: <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>



On 9/3/19 12:12 PM, Leo Korinth wrote:
> On 03/09/2019 01:46, Kim Barrett wrote:
>>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>>> Hi!
>>>> After I got caught doing an unnecessary check on the return value 
>>>> of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be 
>>>> good to do a cleanup in the sources so that others would not fall 
>>>> into this trap. This is the result.
>>>> I have removed some places where the VM will be shut down after 
>>>> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does 
>>>> instead exit). I have also removed lots of unnecessary casts, that 
>>>> might hide bugs.
>>>
>>> Those changes all seem fine, as are the perfMemory changes.
>>>
>>> My only issue is with the places where you can changed allocation of 
>>> a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still 
>>> freed with FREE_C_HEAP_ARRAY which looks odd even though correct (in 
>>> that it's all os::free under the covers anyway). I'm not sure this 
>>> change is worth the potential confusion it may cause.
>>
>> I noticed that too, and then forgot about it.? I agree that?s not 
>> right.? I think those places
>> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
>>
>
> Thank you for finding this. I actually considered implementing the 
> macro FREE_C_HEAP_OBJ as I could not find it. Now I can not understand 
> how I could /miss/ it, though I guess I was looking for a macro with 
> the same signature as FREE_C_HEAP_ARRAY (one taking the type as 
> argument) :-(
>
> As a consequence I also deleted some outdated help text:
>
> - //?? NEW_RESOURCE_ARRAY(type, size)
> - //?? NEW_RESOURCE_OBJ(type)
> - //?? NEW_C_HEAP_ARRAY(type, size)
> - //?? NEW_C_HEAP_OBJ(type, memflags)
> - //?? FREE_C_HEAP_ARRAY(type, old)
> - //?? FREE_C_HEAP_OBJ(objname, type, memflags)
> - //?? char* AllocateHeap(size_t size, const char* name);
> - //?? void? FreeHeap(void* p);
>
> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
> usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to 
> also be an array type when allocated in another place.

I like the removal of the unnecessary casts.? But I don't agree.? I 
don't think NEW_C_HEAP_ARRAY should be used to allocate and 
FREE_C_HEAP_OBJ should be used to deallocate.? That's worse.

Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should 
exist.? They should just use new Type(), where Type is inherited from 
CHeapObj<mtAppropriate>

Thanks,
Coleen

>
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8227168/00_01/
>
> Full:
> http://cr.openjdk.java.net/~lkorinth/8227168/01/
>
> rerunning tests...
>
> Thanks, Leo


From kim.barrett at oracle.com  Tue Sep  3 18:07:56 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 3 Sep 2019 14:07:56 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
Message-ID: <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>

> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
> On 9/3/19 12:12 PM, Leo Korinth wrote:
>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to also be an array type when allocated in another place.
> 
> [?]  But I don't agree.  I don't think NEW_C_HEAP_ARRAY should be used to allocate and FREE_C_HEAP_OBJ should be used to deallocate.  That's worse.

That wasn?t what was suggested.  The suggestion was to always be consistent with the pairing,
e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or use NEW_C_HEAP_OBJ
and FREE_C_HEAP_OBJ, but never mix the pairings for a given object.  I think that?s what the
updated change is doing.

> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should exist.  They should just use new Type(), where Type is inherited from CHeapObj<mtAppropriate>

I was expecting that to have widespread impact, but it seems there are far fewer uses of NEW_C_HEAP_OBJ
than I was expecting.  But I suggest that doing anything about that is out of scope for this change.

I?m also not really fond of the allocation base class approach; C++11 allows some alternatives.


From kim.barrett at oracle.com  Tue Sep  3 18:33:49 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 3 Sep 2019 14:33:49 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
Message-ID: <E9FC8C28-14BB-4C45-9B03-5630E9312C8C@oracle.com>

> On Sep 3, 2019, at 12:12 PM, Leo Korinth <leo.korinth at oracle.com> wrote:
> 
> On 03/09/2019 01:46, Kim Barrett wrote:
>>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>>> Hi!
>>>> After I got caught doing an unnecessary check on the return value of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to do a cleanup in the sources so that others would not fall into this trap. This is the result.
>>>> I have removed some places where the VM will be shut down after NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does instead exit). I have also removed lots of unnecessary casts, that might hide bugs.
>>> 
>>> Those changes all seem fine, as are the perfMemory changes.
>>> 
>>> My only issue is with the places where you can changed allocation of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still freed with FREE_C_HEAP_ARRAY which looks odd even though correct (in that it's all os::free under the covers anyway). I'm not sure this change is worth the potential confusion it may cause.
>> I noticed that too, and then forgot about it.  I agree that?s not right.  I think those places
>> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
> 
> Thank you for finding this. I actually considered implementing the macro FREE_C_HEAP_OBJ as I could not find it. Now I can not understand how I could /miss/ it, though I guess I was looking for a macro with the same signature as FREE_C_HEAP_ARRAY (one taking the type as argument) :-(
> 
> As a consequence I also deleted some outdated help text:
> 
> - //   NEW_RESOURCE_ARRAY(type, size)
> - //   NEW_RESOURCE_OBJ(type)
> - //   NEW_C_HEAP_ARRAY(type, size)
> - //   NEW_C_HEAP_OBJ(type, memflags)
> - //   FREE_C_HEAP_ARRAY(type, old)
> - //   FREE_C_HEAP_OBJ(objname, type, memflags)
> - //   char* AllocateHeap(size_t size, const char* name);
> - //   void  FreeHeap(void* p);

I think just deleting the list of macros and functions isn't right.
Doing so leaves the preceeding two paragraphs dangling, e.g. "The
following macros and function ...".

That whole section of the comment could use some TLC.  That doesn't
need to be part of this change.

> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to also be an array type when allocated in another place.

I think create_multi_counter_query is only paired with the appropriate
overload of destroy_counter_query, and could use NEW/FREE_C_HEAP_OBJ.

The array case only seems to arise with the set member of
MultiCounterQuerySet, which uses NEW/FREE_C_HEAP_ARRAY (in
destroy_multi_counter_query, which is strictly a helper for some
overloads of destroy_counter_query where an array is involved.

But I can see why you might take the simple approach here.  I wonder
why the query types are POD with all these file-scoped create/destroy
helper functions, rather than having constructors and destructors.  I
suspect that would make these questions around the lifetime management
much simpler.

> 
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8227168/00_01/
> 
> Full:
> http://cr.openjdk.java.net/~lkorinth/8227168/01/
> 
> rerunning tests...
> 
> Thanks, Leo

Other than the partial comment deletion, this looks good to me.

I don?t need a new webrev if you are just going to reinstate that partial comment.


From david.holmes at oracle.com  Wed Sep  4 03:35:22 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 13:35:22 +1000
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <E9FC8C28-14BB-4C45-9B03-5630E9312C8C@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <E9FC8C28-14BB-4C45-9B03-5630E9312C8C@oracle.com>
Message-ID: <0e3074a8-0261-6b2b-5094-c44aaa172d3e@oracle.com>

I'll concur with Kim on this. Restore the comment in allocation.hpp 
despite the inaccuracy - or else fix the blatant errors but don't worry 
about elaborating on missing macros.

Thanks,
David

On 4/09/2019 4:33 am, Kim Barrett wrote:
>> On Sep 3, 2019, at 12:12 PM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>
>> On 03/09/2019 01:46, Kim Barrett wrote:
>>>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>>>> Hi!
>>>>> After I got caught doing an unnecessary check on the return value of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would be good to do a cleanup in the sources so that others would not fall into this trap. This is the result.
>>>>> I have removed some places where the VM will be shut down after NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does instead exit). I have also removed lots of unnecessary casts, that might hide bugs.
>>>>
>>>> Those changes all seem fine, as are the perfMemory changes.
>>>>
>>>> My only issue is with the places where you can changed allocation of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still freed with FREE_C_HEAP_ARRAY which looks odd even though correct (in that it's all os::free under the covers anyway). I'm not sure this change is worth the potential confusion it may cause.
>>> I noticed that too, and then forgot about it.  I agree that?s not right.  I think those places
>>> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
>>
>> Thank you for finding this. I actually considered implementing the macro FREE_C_HEAP_OBJ as I could not find it. Now I can not understand how I could /miss/ it, though I guess I was looking for a macro with the same signature as FREE_C_HEAP_ARRAY (one taking the type as argument) :-(
>>
>> As a consequence I also deleted some outdated help text:
>>
>> - //   NEW_RESOURCE_ARRAY(type, size)
>> - //   NEW_RESOURCE_OBJ(type)
>> - //   NEW_C_HEAP_ARRAY(type, size)
>> - //   NEW_C_HEAP_OBJ(type, memflags)
>> - //   FREE_C_HEAP_ARRAY(type, old)
>> - //   FREE_C_HEAP_OBJ(objname, type, memflags)
>> - //   char* AllocateHeap(size_t size, const char* name);
>> - //   void  FreeHeap(void* p);
> 
> I think just deleting the list of macros and functions isn't right.
> Doing so leaves the preceeding two paragraphs dangling, e.g. "The
> following macros and function ...".
> 
> That whole section of the comment could use some TLC.  That doesn't
> need to be part of this change.
> 
>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to also be an array type when allocated in another place.
> 
> I think create_multi_counter_query is only paired with the appropriate
> overload of destroy_counter_query, and could use NEW/FREE_C_HEAP_OBJ.
> 
> The array case only seems to arise with the set member of
> MultiCounterQuerySet, which uses NEW/FREE_C_HEAP_ARRAY (in
> destroy_multi_counter_query, which is strictly a helper for some
> overloads of destroy_counter_query where an array is involved.
> 
> But I can see why you might take the simple approach here.  I wonder
> why the query types are POD with all these file-scoped create/destroy
> helper functions, rather than having constructors and destructors.  I
> suspect that would make these questions around the lifetime management
> much simpler.
> 
>>
>> Incremental:
>> http://cr.openjdk.java.net/~lkorinth/8227168/00_01/
>>
>> Full:
>> http://cr.openjdk.java.net/~lkorinth/8227168/01/
>>
>> rerunning tests...
>>
>> Thanks, Leo
> 
> Other than the partial comment deletion, this looks good to me.
> 
> I don?t need a new webrev if you are just going to reinstate that partial comment.
> 

From david.holmes at oracle.com  Wed Sep  4 09:39:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 19:39:30 +1000
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
Message-ID: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8230422
webrev: http://cr.openjdk.java.net/~dholmes/8230422/webrev/

This is mostly a mechanical change from os::sleep to 
os::naked_short_sleep or os::naked_sleep, but it affects code in 
runtime, jfr, compiler and GC. The patch file is best to use for review 
purposes.

Summary of changes:
- added os::naked_sleep as a wrapper around os::naked_short_sleep for 
sleeps longer than 1 second** - not usable by JavaThreads
- os::sleep now only has the old interruptible path and takes a 
JavaThread parameter rather than thread
- changed os::sleep(thread,millis,false) to 
os::naked_short_sleep(millis) or os::naked_sleep(millis) depending on 
the timeout value
- changed os::sleep(thread,millis,true) to os::sleep(thread,millis) with 
checks/changes where needed to ensure "thread" is a JavaThread

** Many of the calls to this use a VM flag to define the timeout. That 
either defaults to 1 or 0 (not used) but is otherwise unconstrained in 
value. While sleeps longer than one second don't really make sense I 
didn't want to preclude them without there being a range check in place 
for the flag itself.

Testing: tiers 1- 3

I'd appreciate it if someone involved with Shenandoah can check the one 
change in that code.

Thanks,
David

From leo.korinth at oracle.com  Wed Sep  4 11:21:14 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 4 Sep 2019 13:21:14 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <0e3074a8-0261-6b2b-5094-c44aaa172d3e@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <E9FC8C28-14BB-4C45-9B03-5630E9312C8C@oracle.com>
 <0e3074a8-0261-6b2b-5094-c44aaa172d3e@oracle.com>
Message-ID: <6b3b7339-b70c-bd3c-7e01-0fbae8ea2dab@oracle.com>

On 04/09/2019 05:35, David Holmes wrote:
> I'll concur with Kim on this. Restore the comment in allocation.hpp 
> despite the inaccuracy - or else fix the blatant errors but don't worry 
> about elaborating on missing macros.
> 
> Thanks,
> David


how about:

//NEW_RESOURCE_ARRAY*
//REALLOC_RESOURCE_ARRAY*
//FREE_RESOURCE_ARRAY*
//FREE_FAST
//NEW_RESOURCE_OBJ*
//NEW_C_HEAP_ARRAY*
//REALLOC_C_HEAP_ARRAY*
//FREE_C_HEAP_ARRAY*
//NEW_C_HEAP_OBJ*
//FREE_C_HEAP_OBJ
//
//char* AllocateHeap(size_t size, MEMFLAGS flags, const NativeCallStack& 
stack, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType 
alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, 
AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);

It is (at least) better than what is present, I could also list them all:

//NEW_RESOURCE_ARRAY(type, size)
//NEW_RESOURCE_ARRAY_RETURN_NULL(type, size)
//NEW_RESOURCE_ARRAY_IN_THREAD(thread, type, size)
//NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_NULL(thread, type, size)
//REALLOC_RESOURCE_ARRAY(type, old, old_size, new_size)
//REALLOC_RESOURCE_ARRAY_RETURN_NULL(type, old, old_size, new_size)
//FREE_RESOURCE_ARRAY(type, old, size)
//FREE_FAST(old)
//NEW_RESOURCE_OBJ(type)
//NEW_RESOURCE_OBJ_RETURN_NULL(type)
//NEW_C_HEAP_ARRAY3(type, size, memflags, pc, allocfail)
//NEW_C_HEAP_ARRAY2(type, size, memflags, pc)
//NEW_C_HEAP_ARRAY(type, size, memflags)
//NEW_C_HEAP_ARRAY2_RETURN_NULL(type, size, memflags, pc)
//NEW_C_HEAP_ARRAY_RETURN_NULL(type, size, memflags)
//REALLOC_C_HEAP_ARRAY(type, old, size, memflags)
//REALLOC_C_HEAP_ARRAY_RETURN_NULL(type, old, size, memflags)
//FREE_C_HEAP_ARRAY(type, old)
//NEW_C_HEAP_OBJ(type, memflags)
//NEW_C_HEAP_OBJ_RETURN_NULL(type, memflags)
//FREE_C_HEAP_OBJ(objname)
//
//char* AllocateHeap(size_t size, MEMFLAGS flags, const NativeCallStack& 
stack, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType 
alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, 
AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);

I propose the first shorter (asterisked) version.

Thanks,
Leo

> On 4/09/2019 4:33 am, Kim Barrett wrote:
>>> On Sep 3, 2019, at 12:12 PM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>
>>> On 03/09/2019 01:46, Kim Barrett wrote:
>>>>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>>>>> Hi!
>>>>>> After I got caught doing an unnecessary check on the return value 
>>>>>> of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would 
>>>>>> be good to do a cleanup in the sources so that others would not 
>>>>>> fall into this trap. This is the result.
>>>>>> I have removed some places where the VM will be shut down after 
>>>>>> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does 
>>>>>> instead exit). I have also removed lots of unnecessary casts, that 
>>>>>> might hide bugs.
>>>>>
>>>>> Those changes all seem fine, as are the perfMemory changes.
>>>>>
>>>>> My only issue is with the places where you can changed allocation 
>>>>> of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still 
>>>>> freed with FREE_C_HEAP_ARRAY which looks odd even though correct 
>>>>> (in that it's all os::free under the covers anyway). I'm not sure 
>>>>> this change is worth the potential confusion it may cause.
>>>> I noticed that too, and then forgot about it.? I agree that?s not 
>>>> right.? I think those places
>>>> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
>>>
>>> Thank you for finding this. I actually considered implementing the 
>>> macro FREE_C_HEAP_OBJ as I could not find it. Now I can not 
>>> understand how I could /miss/ it, though I guess I was looking for a 
>>> macro with the same signature as FREE_C_HEAP_ARRAY (one taking the 
>>> type as argument) :-(
>>>
>>> As a consequence I also deleted some outdated help text:
>>>
>>> - //?? NEW_RESOURCE_ARRAY(type, size)
>>> - //?? NEW_RESOURCE_OBJ(type)
>>> - //?? NEW_C_HEAP_ARRAY(type, size)
>>> - //?? NEW_C_HEAP_OBJ(type, memflags)
>>> - //?? FREE_C_HEAP_ARRAY(type, old)
>>> - //?? FREE_C_HEAP_OBJ(objname, type, memflags)
>>> - //?? char* AllocateHeap(size_t size, const char* name);
>>> - //?? void? FreeHeap(void* p);
>>
>> I think just deleting the list of macros and functions isn't right.
>> Doing so leaves the preceeding two paragraphs dangling, e.g. "The
>> following macros and function ...".
>>
>> That whole section of the comment could use some TLC.? That doesn't
>> need to be part of this change.
>>
>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
>>> usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able 
>>> to also be an array type when allocated in another place.
>>
>> I think create_multi_counter_query is only paired with the appropriate
>> overload of destroy_counter_query, and could use NEW/FREE_C_HEAP_OBJ.
>>
>> The array case only seems to arise with the set member of
>> MultiCounterQuerySet, which uses NEW/FREE_C_HEAP_ARRAY (in
>> destroy_multi_counter_query, which is strictly a helper for some
>> overloads of destroy_counter_query where an array is involved.
>>
>> But I can see why you might take the simple approach here.? I wonder
>> why the query types are POD with all these file-scoped create/destroy
>> helper functions, rather than having constructors and destructors.? I
>> suspect that would make these questions around the lifetime management
>> much simpler.
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/00_01/
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/01/
>>>
>>> rerunning tests...
>>>
>>> Thanks, Leo
>>
>> Other than the partial comment deletion, this looks good to me.
>>
>> I don?t need a new webrev if you are just going to reinstate that 
>> partial comment.
>>

From stefan.karlsson at oracle.com  Wed Sep  4 11:23:27 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 13:23:27 +0200
Subject: RFR: 8230564: Remove os_ext.hpp
Message-ID: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>

Hi all,

Please review this patch to remove os_ext.hpp.

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

Oracle doesn't need this file anymore. Is anyone else replacing this 
with their own version, or can we simply remove it?

Thanks,
StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 11:23:15 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 13:23:15 +0200
Subject: RFR: 8230561: Remove logTag_ext.hpp
Message-ID: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>

Hi all,

Please review this patch to remove logTag_ext.hpp.

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

Oracle doesn't need this file anymore. Is anyone else replacing this 
with their own version, or can we simply remove it?

Thanks,
StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 11:23:20 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 13:23:20 +0200
Subject: RFR: 8230562: Remove g1HeapSizingPolicy_ext.cpp
Message-ID: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>

Hi all,

Please review this patch to remove g1HeapSizingPolicy_ext.cpp.

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

Oracle doesn't need this file anymore. Is anyone else replacing this 
with their own version, or can we simply remove it?

Thanks,
StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 11:23:24 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 13:23:24 +0200
Subject: RFR: 8230563: Remove arguments_ext.cpp
Message-ID: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>

Hi all,

Please review this patch to remove arguments_ext.cpp.

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

Oracle doesn't need this file anymore. Is anyone else replacing this 
with their own version, or can we simply remove it?

Thanks,
StefanK

From leo.korinth at oracle.com  Wed Sep  4 11:27:33 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 4 Sep 2019 13:27:33 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <6b3b7339-b70c-bd3c-7e01-0fbae8ea2dab@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <E9FC8C28-14BB-4C45-9B03-5630E9312C8C@oracle.com>
 <0e3074a8-0261-6b2b-5094-c44aaa172d3e@oracle.com>
 <6b3b7339-b70c-bd3c-7e01-0fbae8ea2dab@oracle.com>
Message-ID: <0421ac60-6eae-e2f9-4478-e0c2284d4a98@oracle.com>

On 04/09/2019 13:21, Leo Korinth wrote:

> alloc_failmode = AllocFailStrategy::EXIT_OOM);
> //char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, 
> AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);

I missed the last line:

//void FreeHeap(void* p);

Sorry, Leo

From david.holmes at oracle.com  Wed Sep  4 12:52:26 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 22:52:26 +1000
Subject: RFR: 8230561: Remove logTag_ext.hpp
In-Reply-To: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
References: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
Message-ID: <242f7021-eb21-a18e-0975-d4e5b642616a@oracle.com>

Hi Stefan,

On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to remove logTag_ext.hpp.
> 
> https://cr.openjdk.java.net/~stefank/8230561/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230561
> 
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?

Removal is reviewed, assuming noone needs it.

Thanks,
David

> Thanks,
> StefanK

From david.holmes at oracle.com  Wed Sep  4 12:54:40 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 22:54:40 +1000
Subject: RFR: 8230563: Remove arguments_ext.cpp
In-Reply-To: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
References: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
Message-ID: <4b6e387c-35ff-b405-8df6-98f064bc0d18@oracle.com>

Hi Stefan,

On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to remove arguments_ext.cpp.
> 
> https://cr.openjdk.java.net/~stefank/8230563/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230563
> 
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?

Removal is reviewed, assuming noone needs it.

Thanks,
David

> Thanks,
> StefanK

From david.holmes at oracle.com  Wed Sep  4 13:05:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 23:05:30 +1000
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
Message-ID: <06c11182-d1d4-4ce5-d055-c34bc0140923@oracle.com>

Hi Stefan,

On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to remove os_ext.hpp.
> 
> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230564
> 
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?

The removal of os_ext.hpp is fine assuming it is not needed.

I don't see the reason for the change in vm_version.hpp. In its usual 
weird way that comment is actually describing the use of 
VM_Version::initialize() rather than Abstract_VM_Version::initialize().

Thanks,
David

> Thanks,
> StefanK

From leo.korinth at oracle.com  Wed Sep  4 11:16:07 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 4 Sep 2019 13:16:07 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
Message-ID: <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>



On 03/09/2019 20:07, Kim Barrett wrote:
>> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
>> On 9/3/19 12:12 PM, Leo Korinth wrote:
>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able to also be an array type when allocated in another place.
>>
>> [?]  But I don't agree.  I don't think NEW_C_HEAP_ARRAY should be used to allocate and FREE_C_HEAP_OBJ should be used to deallocate.  That's worse.
> 
> That wasn?t what was suggested.  The suggestion was to always be consistent with the pairing,
> e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or use NEW_C_HEAP_OBJ
> and FREE_C_HEAP_OBJ, but never mix the pairings for a given object.  I think that?s what the
> updated change is doing.

That was what I tried to do, your explanation is much better than mine, 
thanks Kim.
> 
>> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should exist.  They should just use new Type(), where Type is inherited from CHeapObj<mtAppropriate>
It is my goal to remove /all/ allocation macros, but I could not fit it 
into this change ;-)

Thanks, Leo
> 
> I was expecting that to have widespread impact, but it seems there are far fewer uses of NEW_C_HEAP_OBJ
> than I was expecting.  But I suggest that doing anything about that is out of scope for this change.
> 
> I?m also not really fond of the allocation base class approach; C++11 allows some alternatives.
> 

From stefan.karlsson at oracle.com  Wed Sep  4 13:31:29 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 15:31:29 +0200
Subject: RFR: 8230563: Remove arguments_ext.cpp
In-Reply-To: <4b6e387c-35ff-b405-8df6-98f064bc0d18@oracle.com>
References: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
 <4b6e387c-35ff-b405-8df6-98f064bc0d18@oracle.com>
Message-ID: <b228e1a8-b366-4c74-be11-135196364703@oracle.com>

Thanks, David.

StefanK

On 2019-09-04 14:54, David Holmes wrote:
> Hi Stefan,
> 
> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove arguments_ext.cpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230563/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230563
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
> 
> Removal is reviewed, assuming noone needs it.
> 
> Thanks,
> David
> 
>> Thanks,
>> StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 13:31:37 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 15:31:37 +0200
Subject: RFR: 8230562: Remove g1HeapSizingPolicy_ext.cpp
In-Reply-To: <e857c6da-9f2d-c97e-8776-6332605992b0@oracle.com>
References: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
 <e857c6da-9f2d-c97e-8776-6332605992b0@oracle.com>
Message-ID: <fdb2fb22-f660-e5e6-ab87-108364541ebc@oracle.com>

Thanks, David.

StefanK

On 2019-09-04 14:53, David Holmes wrote:
> Hi Stefan,
> 
> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove g1HeapSizingPolicy_ext.cpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230562/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230562
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
> 
> Removal is reviewed, assuming noone needs it.
> 
> Thanks,
> David
> 
>> Thanks,
>> StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 13:31:48 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 15:31:48 +0200
Subject: RFR: 8230561: Remove logTag_ext.hpp
In-Reply-To: <242f7021-eb21-a18e-0975-d4e5b642616a@oracle.com>
References: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
 <242f7021-eb21-a18e-0975-d4e5b642616a@oracle.com>
Message-ID: <08158dd0-233c-8c90-f6cd-869d1d3ba916@oracle.com>

Thanks, David.

StefanK

On 2019-09-04 14:52, David Holmes wrote:
> Hi Stefan,
> 
> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove logTag_ext.hpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230561/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230561
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
> 
> Removal is reviewed, assuming noone needs it.
> 
> Thanks,
> David
> 
>> Thanks,
>> StefanK

From stefan.karlsson at oracle.com  Wed Sep  4 13:31:08 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 4 Sep 2019 15:31:08 +0200
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <06c11182-d1d4-4ce5-d055-c34bc0140923@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
 <06c11182-d1d4-4ce5-d055-c34bc0140923@oracle.com>
Message-ID: <ca1d116a-19ca-8cfd-3856-6567d91a8695@oracle.com>

Hi David,

On 2019-09-04 15:05, David Holmes wrote:
> Hi Stefan,
> 
> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove os_ext.hpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230564
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
> 
> The removal of os_ext.hpp is fine assuming it is not needed.
>

Thanks for reviewing.


> I don't see the reason for the change in vm_version.hpp. In its usual 
> weird way that comment is actually describing the use of 
> VM_Version::initialize() rather than Abstract_VM_Version::initialize().

I reverted that change:
  https://cr.openjdk.java.net/~stefank/8230564/webrev.02.delta/
  https://cr.openjdk.java.net/~stefank/8230564/webrev.02/

Thanks,
StefanK

> 
> Thanks,
> David
> 
>> Thanks,
>> StefanK

From coleen.phillimore at oracle.com  Wed Sep  4 13:51:55 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Sep 2019 09:51:55 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
Message-ID: <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>



On 9/4/19 7:16 AM, Leo Korinth wrote:
>
>
> On 03/09/2019 20:07, Kim Barrett wrote:
>>> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
>>> On 9/3/19 12:12 PM, Leo Korinth wrote:
>>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
>>>> usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able 
>>>> to also be an array type when allocated in another place.
>>>
>>> [?]? But I don't agree.? I don't think NEW_C_HEAP_ARRAY should be 
>>> used to allocate and FREE_C_HEAP_OBJ should be used to deallocate.? 
>>> That's worse.
>>
>> That wasn?t what was suggested.? The suggestion was to always be 
>> consistent with the pairing,
>> e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or use 
>> NEW_C_HEAP_OBJ
>> and FREE_C_HEAP_OBJ, but never mix the pairings for a given object.? 
>> I think that?s what the
>> updated change is doing.
>
> That was what I tried to do, your explanation is much better than 
> mine, thanks Kim.
>>
>>> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should 
>>> exist.? They should just use new Type(), where Type is inherited 
>>> from CHeapObj<mtAppropriate>
> It is my goal to remove /all/ allocation macros, but I could not fit 
> it into this change ;-)

How are you going to remove the NEW_C_HEAP_ARRAY macros?? Is that 
somewhere in this thread?? Everything got cut off.? Can you put all this 
in the CR?

What is the latest version of this patch?

Thanks,
Coleen


>
> Thanks, Leo
>>
>> I was expecting that to have widespread impact, but it seems there 
>> are far fewer uses of NEW_C_HEAP_OBJ
>> than I was expecting.? But I suggest that doing anything about that 
>> is out of scope for this change.
>>
>> I?m also not really fond of the allocation base class approach; C++11 
>> allows some alternatives.
>>


From coleen.phillimore at oracle.com  Wed Sep  4 13:56:12 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Sep 2019 09:56:12 -0400
Subject: RFR: 8230561: Remove logTag_ext.hpp
In-Reply-To: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
References: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
Message-ID: <1d93fb87-4910-6bc9-3d2d-f085154ab67d@oracle.com>

Looks good.
Coleen

On 9/4/19 7:23 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove logTag_ext.hpp.
>
> https://cr.openjdk.java.net/~stefank/8230561/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230561
>
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?
>
> Thanks,
> StefanK


From coleen.phillimore at oracle.com  Wed Sep  4 13:56:32 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Sep 2019 09:56:32 -0400
Subject: RFR: 8230563: Remove arguments_ext.cpp
In-Reply-To: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
References: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
Message-ID: <8ea074d0-2131-e75e-9a9c-1d62a710b774@oracle.com>

Looks good.
Coleen

On 9/4/19 7:23 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove arguments_ext.cpp.
>
> https://cr.openjdk.java.net/~stefank/8230563/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230563
>
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?
>
> Thanks,
> StefanK


From coleen.phillimore at oracle.com  Wed Sep  4 13:56:53 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 4 Sep 2019 09:56:53 -0400
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
Message-ID: <2510f04a-ad35-1e3f-e934-b269fc2a97db@oracle.com>

Looks good.
Coleen

On 9/4/19 7:23 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please review this patch to remove os_ext.hpp.
>
> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230564
>
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?
>
> Thanks,
> StefanK


From david.holmes at oracle.com  Wed Sep  4 12:53:40 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Sep 2019 22:53:40 +1000
Subject: RFR: 8230562: Remove g1HeapSizingPolicy_ext.cpp
In-Reply-To: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
References: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
Message-ID: <e857c6da-9f2d-c97e-8776-6332605992b0@oracle.com>

Hi Stefan,

On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to remove g1HeapSizingPolicy_ext.cpp.
> 
> https://cr.openjdk.java.net/~stefank/8230562/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230562
> 
> Oracle doesn't need this file anymore. Is anyone else replacing this 
> with their own version, or can we simply remove it?

Removal is reviewed, assuming noone needs it.

Thanks,
David

> Thanks,
> StefanK

From leo.korinth at oracle.com  Wed Sep  4 14:44:00 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 4 Sep 2019 16:44:00 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
Message-ID: <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>



On 04/09/2019 15:51, coleen.phillimore at oracle.com wrote:
> 
> 
> On 9/4/19 7:16 AM, Leo Korinth wrote:
>>
>>
>> On 03/09/2019 20:07, Kim Barrett wrote:
>>>> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
>>>> On 9/3/19 12:12 PM, Leo Korinth wrote:
>>>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
>>>>> usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able 
>>>>> to also be an array type when allocated in another place.
>>>>
>>>> [?]? But I don't agree.? I don't think NEW_C_HEAP_ARRAY should be 
>>>> used to allocate and FREE_C_HEAP_OBJ should be used to deallocate. 
>>>> That's worse.
>>>
>>> That wasn?t what was suggested.? The suggestion was to always be 
>>> consistent with the pairing,
>>> e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or use 
>>> NEW_C_HEAP_OBJ
>>> and FREE_C_HEAP_OBJ, but never mix the pairings for a given object. I 
>>> think that?s what the
>>> updated change is doing.
>>
>> That was what I tried to do, your explanation is much better than 
>> mine, thanks Kim.
>>>
>>>> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should 
>>>> exist.? They should just use new Type(), where Type is inherited 
>>>> from CHeapObj<mtAppropriate>
>> It is my goal to remove /all/ allocation macros, but I could not fit 
>> it into this change ;-)
> 
> How are you going to remove the NEW_C_HEAP_ARRAY macros?? Is that 
> somewhere in this thread?? Everything got cut off.? Can you put all this 
> in the CR?

I am looking into replacing them with operator new, but I would like to 
see that I have a working sane version before proposing anything.

It is not related to this in any way. I feel these changes improve the 
current situation, even though NEW_C_HEAP_OBJ might not be the best 
solution, it is still /better/ than faking allocation of an array. I 
also believe it is better to remove bad usage before it is copied than 
doing nothing because the improvement is not perfect.

> What is the latest version of this patch?

I have no working code for removing those macros, but I am looking into 
it. Hopefully it will work, but lets not waste time on my ideas.

Thanks,
Leo

> 
> Thanks,
> Coleen
> 
> 
>>
>> Thanks, Leo
>>>
>>> I was expecting that to have widespread impact, but it seems there 
>>> are far fewer uses of NEW_C_HEAP_OBJ
>>> than I was expecting.? But I suggest that doing anything about that 
>>> is out of scope for this change.
>>>
>>> I?m also not really fond of the allocation base class approach; C++11 
>>> allows some alternatives.
>>>
> 

From kim.barrett at oracle.com  Wed Sep  4 16:25:03 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Sep 2019 12:25:03 -0400
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
Message-ID: <6A59F8EB-650F-4464-92D0-4B42B99EA554@oracle.com>

> On Sep 4, 2019, at 5:39 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8230422
> webrev: http://cr.openjdk.java.net/~dholmes/8230422/webrev/
> 
> This is mostly a mechanical change from os::sleep to os::naked_short_sleep or os::naked_sleep, but it affects code in runtime, jfr, compiler and GC. The patch file is best to use for review purposes.
> 
> Summary of changes:
> - added os::naked_sleep as a wrapper around os::naked_short_sleep for sleeps longer than 1 second** - not usable by JavaThreads
> - os::sleep now only has the old interruptible path and takes a JavaThread parameter rather than thread
> - changed os::sleep(thread,millis,false) to os::naked_short_sleep(millis) or os::naked_sleep(millis) depending on the timeout value
> - changed os::sleep(thread,millis,true) to os::sleep(thread,millis) with checks/changes where needed to ensure "thread" is a JavaThread
> 
> ** Many of the calls to this use a VM flag to define the timeout. That either defaults to 1 or 0 (not used) but is otherwise unconstrained in value. While sleeps longer than one second don't really make sense I didn't want to preclude them without there being a range check in place for the flag itself.
> 
> Testing: tiers 1- 3
> 
> I'd appreciate it if someone involved with Shenandoah can check the one change in that code.
> 
> Thanks,
> David

Looks good.


From mikhailo.seledtsov at oracle.com  Wed Sep  4 20:28:51 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Wed, 4 Sep 2019 13:28:51 -0700
Subject: RFR(T): 8230624: [TESTBUG] Problemlist JFR
 compiler/TestCodeSweeper.java
Message-ID: <51599b7e-d5e0-9abd-8a90-62efa63a638f@oracle.com>

This test times out intermittently. Problem listing the test until the 
underlying issue is fixed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8230624

Change:

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -886,6 +886,7 @@
 ?jdk/jfr/api/recording/event/TestPeriod.java 8215890??? generic-all
 ?jdk/jfr/event/io/EvilInstrument.java 8221331??? generic-all
 ?jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 
8228990,8229370??? generic-all
+jdk/jfr/event/compiler/TestCodeSweeper.java 8225209??? generic-all

 ?############################################################################


Thanks,

Misha


From erik.gahlin at oracle.com  Wed Sep  4 20:48:34 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 4 Sep 2019 22:48:34 +0200
Subject: RFR(T): 8230624: [TESTBUG] Problemlist JFR
 compiler/TestCodeSweeper.java
In-Reply-To: <51599b7e-d5e0-9abd-8a90-62efa63a638f@oracle.com>
References: <51599b7e-d5e0-9abd-8a90-62efa63a638f@oracle.com>
Message-ID: <5D702322.7030205@oracle.com>

Looks good.

Erik

> This test times out intermittently. Problem listing the test until the 
> underlying issue is fixed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8230624
>
> Change:
>
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -886,6 +886,7 @@
>  jdk/jfr/api/recording/event/TestPeriod.java 8215890 generic-all
>  jdk/jfr/event/io/EvilInstrument.java 8221331    generic-all
>  jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 
> 8228990,8229370    generic-all
> +jdk/jfr/event/compiler/TestCodeSweeper.java 8225209 generic-all
>
>  ############################################################################ 
>
>
>
> Thanks,
>
> Misha
>


From mikhailo.seledtsov at oracle.com  Wed Sep  4 20:58:41 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Wed, 4 Sep 2019 13:58:41 -0700
Subject: RFR(T): 8230624: [TESTBUG] Problemlist JFR
 compiler/TestCodeSweeper.java
In-Reply-To: <5D702322.7030205@oracle.com>
References: <51599b7e-d5e0-9abd-8a90-62efa63a638f@oracle.com>
 <5D702322.7030205@oracle.com>
Message-ID: <f752381f-01dd-3c8c-90f2-82cd2d3e063a@oracle.com>

Thank you. Just pushed the change.

On 9/4/19 1:48 PM, Erik Gahlin wrote:
> Looks good.
>
> Erik
>
>> This test times out intermittently. Problem listing the test until 
>> the underlying issue is fixed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230624
>>
>> Change:
>>
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -886,6 +886,7 @@
>> ?jdk/jfr/api/recording/event/TestPeriod.java 8215890 generic-all
>> ?jdk/jfr/event/io/EvilInstrument.java 8221331??? generic-all
>> ?jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java 
>> 8228990,8229370??? generic-all
>> +jdk/jfr/event/compiler/TestCodeSweeper.java 8225209 generic-all
>>
>> ?############################################################################ 
>>
>>
>>
>> Thanks,
>>
>> Misha
>>
>

From brent.christian at oracle.com  Wed Sep  4 21:12:25 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 4 Sep 2019 14:12:25 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded but
 not linked Class
Message-ID: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>

Hi,

Please review my fix for JDK-8212117[1].  The webrev is here:

http://cr.openjdk.java.net/~bchristi/8212117/webrev09/

There is also a CSR[2] in need of review.

The spec for the 2-arg and 3-arg Class.forName() methods states they 
will "locate, load, and link" the class, however the linking part is not 
ensured to happen.

Although the VM spec allows flexibility WRT when classes are linked, 
this is a corner where the Class.forName() spec is not being upheld. 
While this is not an issue for most usages,  8181144 [3] demonstrates 
how this can be a problem (with the debugging interface, in this case).

This fix ensures that linking happens during the course of 
Class.forName().  Class.forName() already @throws LinkageError, so no 
spec change is needed there. MethodHandles.Lookup.findClass() needs a 
small spec update, due to calling Class.forName with init=false,

Of course Errors are not required to be caught.  It is therefore 
possible that the new behavior could introduce previously unseen, 
possibly unhandled LinkageErrors.  A new VM flag 
(-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
behavior (to keep such code running until it can be updated).

This change surfaced a couple new "A JNI error has occurred" situations 
(see 8181033[5]) in the Launcher, by way of
   test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
(using the 3-arg Class::forName, detailed in the bug report[4]),
and
   test/jdk/tools/launcher/modules/basic/LauncherErrors.java
(using the 2-arg Class::forName).

The Launcher is updated to maintain non-confusing error messages :).

The new test included with this fix ensures that 8181144[3] is 
addressed.  Thanks go to Serguei Spitsyn for writing the test.

Automated corelibs and hotspot tests pass cleanly.

Thanks,
-Brent

--
1. https://bugs.openjdk.java.net/browse/JDK-8212117

2. https://bugs.openjdk.java.net/browse/JDK-8222071

3. https://bugs.openjdk.java.net/browse/JDK-8181144

4. 
https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986

5. https://bugs.openjdk.java.net/browse/JDK-8181033


From daniel.daugherty at oracle.com  Wed Sep  4 22:06:37 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 4 Sep 2019 18:06:37 -0400
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
Message-ID: <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com>

Brent,

You currently have '-XX:+ClassForNameDeferLinking' as a 'product' 
option, but
product options are harder to remove down the road. Would it be better as a
diagnostic option? A diagnostic option requires 
'-XX:+UnlockDiagnosticVMOptions'
to be specified before it can be used, e.g.:

 ??? java -XX:+UnlockDiagnosticVMOptions -XX:+ClassForNameDeferLinking Foo

so it is a bit harder to use, but maybe that's a Good Thing (TM).

Dan


On 9/4/19 5:12 PM, Brent Christian wrote:
> Hi,
>
> Please review my fix for JDK-8212117[1].? The webrev is here:
>
> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
>
> There is also a CSR[2] in need of review.
>
> The spec for the 2-arg and 3-arg Class.forName() methods states they 
> will "locate, load, and link" the class, however the linking part is 
> not ensured to happen.
>
> Although the VM spec allows flexibility WRT when classes are linked, 
> this is a corner where the Class.forName() spec is not being upheld. 
> While this is not an issue for most usages,? 8181144 [3] demonstrates 
> how this can be a problem (with the debugging interface, in this case).
>
> This fix ensures that linking happens during the course of 
> Class.forName().? Class.forName() already @throws LinkageError, so no 
> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
> small spec update, due to calling Class.forName with init=false,
>
> Of course Errors are not required to be caught.? It is therefore 
> possible that the new behavior could introduce previously unseen, 
> possibly unhandled LinkageErrors.? A new VM flag 
> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
> behavior (to keep such code running until it can be updated).
>
> This change surfaced a couple new "A JNI error has occurred" 
> situations (see 8181033[5]) in the Launcher, by way of
> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
> (using the 3-arg Class::forName, detailed in the bug report[4]),
> and
> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
> (using the 2-arg Class::forName).
>
> The Launcher is updated to maintain non-confusing error messages :).
>
> The new test included with this fix ensures that 8181144[3] is 
> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>
> Automated corelibs and hotspot tests pass cleanly.
>
> Thanks,
> -Brent
>
> -- 
> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>
> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>
> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>
> 4. 
> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986
>
> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>


From david.holmes at oracle.com  Wed Sep  4 22:08:03 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Sep 2019 08:08:03 +1000
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <6A59F8EB-650F-4464-92D0-4B42B99EA554@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
 <6A59F8EB-650F-4464-92D0-4B42B99EA554@oracle.com>
Message-ID: <5573a496-1d8c-5558-5c70-83c2f72f5a8e@oracle.com>

Hi Kim,

Thanks for looking at this!

FTR I should have mentioned Kim is the one who suggested this particular 
migration.

Cheers,
David

On 5/09/2019 2:25 am, Kim Barrett wrote:
>> On Sep 4, 2019, at 5:39 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8230422
>> webrev: http://cr.openjdk.java.net/~dholmes/8230422/webrev/
>>
>> This is mostly a mechanical change from os::sleep to os::naked_short_sleep or os::naked_sleep, but it affects code in runtime, jfr, compiler and GC. The patch file is best to use for review purposes.
>>
>> Summary of changes:
>> - added os::naked_sleep as a wrapper around os::naked_short_sleep for sleeps longer than 1 second** - not usable by JavaThreads
>> - os::sleep now only has the old interruptible path and takes a JavaThread parameter rather than thread
>> - changed os::sleep(thread,millis,false) to os::naked_short_sleep(millis) or os::naked_sleep(millis) depending on the timeout value
>> - changed os::sleep(thread,millis,true) to os::sleep(thread,millis) with checks/changes where needed to ensure "thread" is a JavaThread
>>
>> ** Many of the calls to this use a VM flag to define the timeout. That either defaults to 1 or 0 (not used) but is otherwise unconstrained in value. While sleeps longer than one second don't really make sense I didn't want to preclude them without there being a range check in place for the flag itself.
>>
>> Testing: tiers 1- 3
>>
>> I'd appreciate it if someone involved with Shenandoah can check the one change in that code.
>>
>> Thanks,
>> David
> 
> Looks good.
> 

From david.holmes at oracle.com  Thu Sep  5 05:36:19 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Sep 2019 15:36:19 +1000
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com>
Message-ID: <fd939498-0658-ecfe-3016-7c028f1574b0@oracle.com>

Hi Dan,

With my CSR Group member hat on ....

On 5/09/2019 8:06 am, Daniel D. Daugherty wrote:
> Brent,
> 
> You currently have '-XX:+ClassForNameDeferLinking' as a 'product' 
> option, but
> product options are harder to remove down the road. Would it be better as a
> diagnostic option? A diagnostic option requires 

Whether a flag is product or diagnostic (or experimental) should be a 
basic property of the flag based on its purpose. I would not want to see 
a trend of making new flags diagnostic just because it is easier to get 
rid of them later. The expectation with this fix and flag (which I've 
been heavily involved in) is that production code may be impacted by the 
change and need to use the flag to restore previous behaviour. So it 
really is a product flag that end users should be comfortable in using 
if they need it.

The removal process for a product flag is phased (deprecate, obsolete, 
expire) but not particularly onerous. There is an expectation that this 
flag may be deprecated in 15 as it is intended as a transitional flag.

Thanks,
David
-----

> '-XX:+UnlockDiagnosticVMOptions'
> to be specified before it can be used, e.g.:
> 
>  ??? java -XX:+UnlockDiagnosticVMOptions -XX:+ClassForNameDeferLinking Foo
> 
> so it is a bit harder to use, but maybe that's a Good Thing (TM).
> 
> Dan
> 
> 
> On 9/4/19 5:12 PM, Brent Christian wrote:
>> Hi,
>>
>> Please review my fix for JDK-8212117[1].? The webrev is here:
>>
>> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
>>
>> There is also a CSR[2] in need of review.
>>
>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>> will "locate, load, and link" the class, however the linking part is 
>> not ensured to happen.
>>
>> Although the VM spec allows flexibility WRT when classes are linked, 
>> this is a corner where the Class.forName() spec is not being upheld. 
>> While this is not an issue for most usages,? 8181144 [3] demonstrates 
>> how this can be a problem (with the debugging interface, in this case).
>>
>> This fix ensures that linking happens during the course of 
>> Class.forName().? Class.forName() already @throws LinkageError, so no 
>> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
>> small spec update, due to calling Class.forName with init=false,
>>
>> Of course Errors are not required to be caught.? It is therefore 
>> possible that the new behavior could introduce previously unseen, 
>> possibly unhandled LinkageErrors.? A new VM flag 
>> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
>> behavior (to keep such code running until it can be updated).
>>
>> This change surfaced a couple new "A JNI error has occurred" 
>> situations (see 8181033[5]) in the Launcher, by way of
>> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>> and
>> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>> (using the 2-arg Class::forName).
>>
>> The Launcher is updated to maintain non-confusing error messages :).
>>
>> The new test included with this fix ensures that 8181144[3] is 
>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>
>> Automated corelibs and hotspot tests pass cleanly.
>>
>> Thanks,
>> -Brent
>>
>> -- 
>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>
>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>
>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>
>> 4. 
>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>
>>
>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>
> 

From david.holmes at oracle.com  Thu Sep  5 06:03:09 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Sep 2019 16:03:09 +1000
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <ca1d116a-19ca-8cfd-3856-6567d91a8695@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
 <06c11182-d1d4-4ce5-d055-c34bc0140923@oracle.com>
 <ca1d116a-19ca-8cfd-3856-6567d91a8695@oracle.com>
Message-ID: <3e858169-5162-9540-657f-0156381ae931@oracle.com>

Update looks good.

Thanks,
David

On 4/09/2019 11:31 pm, Stefan Karlsson wrote:
> Hi David,
> 
> On 2019-09-04 15:05, David Holmes wrote:
>> Hi Stefan,
>>
>> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to remove os_ext.hpp.
>>>
>>> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
>>> https://bugs.openjdk.java.net/browse/JDK-8230564
>>>
>>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>>> with their own version, or can we simply remove it?
>>
>> The removal of os_ext.hpp is fine assuming it is not needed.
>>
> 
> Thanks for reviewing.
> 
> 
>> I don't see the reason for the change in vm_version.hpp. In its usual 
>> weird way that comment is actually describing the use of 
>> VM_Version::initialize() rather than Abstract_VM_Version::initialize().
> 
> I reverted that change:
>  ?https://cr.openjdk.java.net/~stefank/8230564/webrev.02.delta/
>  ?https://cr.openjdk.java.net/~stefank/8230564/webrev.02/
> 
> Thanks,
> StefanK
> 
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> StefanK

From david.holmes at oracle.com  Thu Sep  5 07:52:29 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Sep 2019 17:52:29 +1000
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
Message-ID: <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com>

Hi Brent,

Good to see this all come together :)

A couple of comments below.

On 5/09/2019 7:12 am, Brent Christian wrote:
> Hi,
> 
> Please review my fix for JDK-8212117[1].? The webrev is here:
> 
> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/

So to clarify for others any current caller to 
find_class_from_class_loader that passes true for "init" was already 
implicitly asking for a linked class (as you must be linked before you 
can be initialized). With that in mind I would suggest that in 
find_class_from_class_loader you add an assert:

! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, 
jboolean init, jboolean link,
                                       Handle loader, Handle 
protection_domain,
                                       jboolean throwError, TRAPS) {
+assert((init && link) || !init, "incorrect use of init/link arguments");

just to ensure the callers understand this.

Aside: in looking at this I've spotted another existing bug. JNI 
FindClass is not specified to perform class initialization, but the 
implementation passes init=true!

---

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

I don't see the need for the new note given it already has

* @throws LinkageError if the linkage fails

---

src/java.base/share/classes/sun/launcher/LauncherHelper.java

So to clarify, the launcher would previously load the main class without 
linking via:

    mainClass = LoadMainClass(env, mode, what);
    CHECK_EXCEPTION_NULL_LEAVE(mainClass);

and then it would invoke the main method which implicitly initialized 
which implicitly linked and so any exceptions related to linking would 
be handled when the main thread detaches, and it all gets reported 
nicely. But now that we link earlier the exception could be pending 
after LoadMainClass and so we would "abort". So you catch that 
unexpected exception in the LauncherHelper.

Is AccessControlException the only exception, that is not a 
LinkageError, that might be thrown when linking? I would think a number 
of others are possible - in particular IllegalAccessError might occur 
during verification. Other than the fact a test obviously triggered 
this, it's not clear why ACE should be singled out here. ??

---

test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java

45     // public static void foo(Foo f) { }

Unclear why this exists. Also the test refers initially to class Foo but 
then uses Foo2 and Foo3. ??

Otherwise all seems good.

> There is also a CSR[2] in need of review.

I've added a couple of comments and will add myself as a reviewer once 
things are near finalized.

Thanks,
David
-----

> 
> The spec for the 2-arg and 3-arg Class.forName() methods states they 
> will "locate, load, and link" the class, however the linking part is not 
> ensured to happen.
> 
> Although the VM spec allows flexibility WRT when classes are linked, 
> this is a corner where the Class.forName() spec is not being upheld. 
> While this is not an issue for most usages,? 8181144 [3] demonstrates 
> how this can be a problem (with the debugging interface, in this case).
> 
> This fix ensures that linking happens during the course of 
> Class.forName().? Class.forName() already @throws LinkageError, so no 
> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
> small spec update, due to calling Class.forName with init=false,
> 
> Of course Errors are not required to be caught.? It is therefore 
> possible that the new behavior could introduce previously unseen, 
> possibly unhandled LinkageErrors.? A new VM flag 
> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
> behavior (to keep such code running until it can be updated).
> 
> This change surfaced a couple new "A JNI error has occurred" situations 
> (see 8181033[5]) in the Launcher, by way of
>  ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
> (using the 3-arg Class::forName, detailed in the bug report[4]),
> and
>  ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
> (using the 2-arg Class::forName).
> 
> The Launcher is updated to maintain non-confusing error messages :).
> 
> The new test included with this fix ensures that 8181144[3] is 
> addressed.? Thanks go to Serguei Spitsyn for writing the test.
> 
> Automated corelibs and hotspot tests pass cleanly.
> 
> Thanks,
> -Brent
> 
> -- 
> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
> 
> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
> 
> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
> 
> 4. 
> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
> 
> 
> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
> 

From stefan.karlsson at oracle.com  Thu Sep  5 08:04:22 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Sep 2019 10:04:22 +0200
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <3e858169-5162-9540-657f-0156381ae931@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
 <06c11182-d1d4-4ce5-d055-c34bc0140923@oracle.com>
 <ca1d116a-19ca-8cfd-3856-6567d91a8695@oracle.com>
 <3e858169-5162-9540-657f-0156381ae931@oracle.com>
Message-ID: <277e5f3c-4b7e-1aab-883b-4e3971e2049b@oracle.com>

Thanks, David.

StefanK

On 2019-09-05 08:03, David Holmes wrote:
> Update looks good.
> 
> Thanks,
> David
> 
> On 4/09/2019 11:31 pm, Stefan Karlsson wrote:
>> Hi David,
>>
>> On 2019-09-04 15:05, David Holmes wrote:
>>> Hi Stefan,
>>>
>>> On 4/09/2019 9:23 pm, Stefan Karlsson wrote:
>>>> Hi all,
>>>>
>>>> Please review this patch to remove os_ext.hpp.
>>>>
>>>> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
>>>> https://bugs.openjdk.java.net/browse/JDK-8230564
>>>>
>>>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>>>> with their own version, or can we simply remove it?
>>>
>>> The removal of os_ext.hpp is fine assuming it is not needed.
>>>
>>
>> Thanks for reviewing.
>>
>>
>>> I don't see the reason for the change in vm_version.hpp. In its usual 
>>> weird way that comment is actually describing the use of 
>>> VM_Version::initialize() rather than Abstract_VM_Version::initialize().
>>
>> I reverted that change:
>> ??https://cr.openjdk.java.net/~stefank/8230564/webrev.02.delta/
>> ??https://cr.openjdk.java.net/~stefank/8230564/webrev.02/
>>
>> Thanks,
>> StefanK
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> StefanK

From stefan.karlsson at oracle.com  Thu Sep  5 08:04:56 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Sep 2019 10:04:56 +0200
Subject: RFR: 8230564: Remove os_ext.hpp
In-Reply-To: <2510f04a-ad35-1e3f-e934-b269fc2a97db@oracle.com>
References: <46e1e98b-e2d8-c2e4-570a-2f23abfa60d6@oracle.com>
 <2510f04a-ad35-1e3f-e934-b269fc2a97db@oracle.com>
Message-ID: <3a464964-539a-57ee-1c5d-09cdd457d5d0@oracle.com>

Thanks, Coleen.

StefanK

On 2019-09-04 15:56, coleen.phillimore at oracle.com wrote:
> Looks good.
> Coleen
> 
> On 9/4/19 7:23 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove os_ext.hpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230564/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230564
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
>>
>> Thanks,
>> StefanK
> 

From stefan.karlsson at oracle.com  Thu Sep  5 08:05:07 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Sep 2019 10:05:07 +0200
Subject: RFR: 8230563: Remove arguments_ext.cpp
In-Reply-To: <8ea074d0-2131-e75e-9a9c-1d62a710b774@oracle.com>
References: <3a7b0677-c3c9-e98f-f794-f8abaf235376@oracle.com>
 <8ea074d0-2131-e75e-9a9c-1d62a710b774@oracle.com>
Message-ID: <36f1e184-b996-06ef-8319-36a03ee62462@oracle.com>

Thanks, Coleen.

StefanK

On 2019-09-04 15:56, coleen.phillimore at oracle.com wrote:
> Looks good.
> Coleen
> 
> On 9/4/19 7:23 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove arguments_ext.cpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230563/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230563
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
>>
>> Thanks,
>> StefanK
> 

From stefan.karlsson at oracle.com  Thu Sep  5 08:05:18 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Thu, 5 Sep 2019 10:05:18 +0200
Subject: RFR: 8230561: Remove logTag_ext.hpp
In-Reply-To: <1d93fb87-4910-6bc9-3d2d-f085154ab67d@oracle.com>
References: <ef8c7c8c-c212-f308-2cb9-d67d86a87710@oracle.com>
 <1d93fb87-4910-6bc9-3d2d-f085154ab67d@oracle.com>
Message-ID: <3a7cd065-03b7-310a-f08e-590ef8f76915@oracle.com>

Thanks, Coleen.

StefanK

On 2019-09-04 15:56, coleen.phillimore at oracle.com wrote:
> Looks good.
> Coleen
> 
> On 9/4/19 7:23 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to remove logTag_ext.hpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230561/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230561
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this 
>> with their own version, or can we simply remove it?
>>
>> Thanks,
>> StefanK
> 

From daniel.daugherty at oracle.com  Thu Sep  5 13:33:02 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 5 Sep 2019 09:33:02 -0400
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <fd939498-0658-ecfe-3016-7c028f1574b0@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <4411374a-0d04-2a65-230f-d0875a981c15@oracle.com>
 <fd939498-0658-ecfe-3016-7c028f1574b0@oracle.com>
Message-ID: <25bb09b5-bd93-d59f-863b-41594629b06c@oracle.com>

On 9/5/19 1:36 AM, David Holmes wrote:
> Hi Dan,
>
> With my CSR Group member hat on ....
>
> On 5/09/2019 8:06 am, Daniel D. Daugherty wrote:
>> Brent,
>>
>> You currently have '-XX:+ClassForNameDeferLinking' as a 'product' 
>> option, but
>> product options are harder to remove down the road. Would it be 
>> better as a
>> diagnostic option? A diagnostic option requires 
>
> Whether a flag is product or diagnostic (or experimental) should be a 
> basic property of the flag based on its purpose. I would not want to 
> see a trend of making new flags diagnostic just because it is easier 
> to get rid of them later. The expectation with this fix and flag 
> (which I've been heavily involved in) is that production code may be 
> impacted by the change and need to use the flag to restore previous 
> behaviour. So it really is a product flag that end users should be 
> comfortable in using if they need 
> it.

This is the key phrase:

 > production code may be impacted by the change and need to
 > use the flag to restore previous behaviour.

Thanks for making that clear. Maybe I missed it in what I read,
but it is now clear that this should be a product flag.

Dan

>
> The removal process for a product flag is phased (deprecate, obsolete, 
> expire) but not particularly onerous. There is an expectation that 
> this flag may be deprecated in 15 as it is intended as a transitional 
> flag.
>
> Thanks,
> David
> -----
>
>> '-XX:+UnlockDiagnosticVMOptions'
>> to be specified before it can be used, e.g.:
>>
>> ???? java -XX:+UnlockDiagnosticVMOptions 
>> -XX:+ClassForNameDeferLinking Foo
>>
>> so it is a bit harder to use, but maybe that's a Good Thing (TM).
>>
>> Dan
>>
>>
>> On 9/4/19 5:12 PM, Brent Christian wrote:
>>> Hi,
>>>
>>> Please review my fix for JDK-8212117[1].? The webrev is here:
>>>
>>> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
>>>
>>> There is also a CSR[2] in need of review.
>>>
>>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>>> will "locate, load, and link" the class, however the linking part is 
>>> not ensured to happen.
>>>
>>> Although the VM spec allows flexibility WRT when classes are linked, 
>>> this is a corner where the Class.forName() spec is not being upheld. 
>>> While this is not an issue for most usages, 8181144 [3] demonstrates 
>>> how this can be a problem (with the debugging interface, in this case).
>>>
>>> This fix ensures that linking happens during the course of 
>>> Class.forName().? Class.forName() already @throws LinkageError, so 
>>> no spec change is needed there. MethodHandles.Lookup.findClass() 
>>> needs a small spec update, due to calling Class.forName with 
>>> init=false,
>>>
>>> Of course Errors are not required to be caught.? It is therefore 
>>> possible that the new behavior could introduce previously unseen, 
>>> possibly unhandled LinkageErrors.? A new VM flag 
>>> (-XX:+ClassForNameDeferLinking) is introduced to restore the 
>>> previous behavior (to keep such code running until it can be updated).
>>>
>>> This change surfaced a couple new "A JNI error has occurred" 
>>> situations (see 8181033[5]) in the Launcher, by way of
>>> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>>> and
>>> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>>> (using the 2-arg Class::forName).
>>>
>>> The Launcher is updated to maintain non-confusing error messages :).
>>>
>>> The new test included with this fix ensures that 8181144[3] is 
>>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>>
>>> Automated corelibs and hotspot tests pass cleanly.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> -- 
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>>
>>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>>
>>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>>
>>> 4. 
>>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>>
>>>
>>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>>
>>


From david.holmes at oracle.com  Tue Sep  3 09:14:40 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Sep 2019 19:14:40 +1000
Subject: RFR: 8230466: check malloc/calloc results in jdk.hotspot.agent
In-Reply-To: <AM6PR02MB50787A456E9A8F196330817693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB50787A456E9A8F196330817693B90@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <c21dd37f-f95e-f232-4a88-438eeb725766@oracle.com>

Hi Matthias,

Re-directing to serviceability-dev.

David

On 3/09/2019 5:42 pm, Baesken, Matthias wrote:
> Hello, please review the following small fix .
> 
> In   jdk.hotspot.agent  native code (linux / macosx)   we miss to check the  result of malloc/calloc a few times .
> This should be  adjusted.
> Additionally  I added initialization  to the symtab  array  in  symtab.c   (by calling memset  to make sure we have a defined state )  .
> 
> 
> 
> One question (was not really sure about this one so I did not change it so far) :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230466.0/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.frames.html
> 
> 359 void destroy_symtab(symtab_t* symtab) {
> 360   if (!symtab) return;
> 361   free(symtab->strs);
> 362   free(symtab->symbols);
> 363   free(symtab);
> 364 }
> 
> 
> 
> Here we miss to close   symtab->hash_table   (opened by  dbopen) ,  is it needed  (haven't  used dbopen much - maybe someone can comment on this)?
> 
> 
> bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8230466
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8230466.0/
> 
> 
> Thanks and best regards, Matthias
> 

From daniel.daugherty at oracle.com  Thu Sep  5 21:16:47 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 5 Sep 2019 17:16:47 -0400
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
Message-ID: <8b91ab12-7e11-6b9c-57ff-1ddb68a478a8@oracle.com>

On 9/4/19 5:39 AM, David Holmes wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8230422
> webrev: http://cr.openjdk.java.net/~dholmes/8230422/webrev/
>
> This is mostly a mechanical change from os::sleep to 
> os::naked_short_sleep or os::naked_sleep, but it affects code in 
> runtime, jfr, compiler and GC. The patch file is best to use for 
> review purposes.

Thumbs up. I used the patch file for everything except for:

 ??? src/hotspot/share/runtime/os.cpp

That file needed frames... :-)

Dan

>
> Summary of changes:
> - added os::naked_sleep as a wrapper around os::naked_short_sleep for 
> sleeps longer than 1 second** - not usable by JavaThreads
> - os::sleep now only has the old interruptible path and takes a 
> JavaThread parameter rather than thread
> - changed os::sleep(thread,millis,false) to 
> os::naked_short_sleep(millis) or os::naked_sleep(millis) depending on 
> the timeout value
> - changed os::sleep(thread,millis,true) to os::sleep(thread,millis) 
> with checks/changes where needed to ensure "thread" is a JavaThread
>
> ** Many of the calls to this use a VM flag to define the timeout. That 
> either defaults to 1 or 0 (not used) but is otherwise unconstrained in 
> value. While sleeps longer than one second don't really make sense I 
> didn't want to preclude them without there being a range check in 
> place for the flag itself.
>
> Testing: tiers 1- 3
>
> I'd appreciate it if someone involved with Shenandoah can check the 
> one change in that code.
>
> Thanks,
> David


From joe.darcy at oracle.com  Thu Sep  5 22:30:56 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 5 Sep 2019 15:30:56 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
Message-ID: <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>

Hello,

For the doc changes in MethodHandle, please supplement the paragraph

1937????????? * <p>
1938????????? * Note that this method throws errors related to loading 
and linking as
1939????????? * specified in Sections 12.2 and 12.3 of <em>The Java Language
1940????????? * Specification</em>.

with @jls tags like

@jls 12.2 Loading of Classes and Interfaces
@jsl 12.3 Linking of Classes and Interfaces

as done elsewhere in the base module. I think it would be slightly 
better to remove the section numbers from the main text but keep them in 
the @jls tags since it is now possible to check that the listed name of 
the section matches what is in the JLS.

Thanks,

-Joe


On 9/4/2019 2:12 PM, Brent Christian wrote:
> Hi,
>
> Please review my fix for JDK-8212117[1].? The webrev is here:
>
> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
>
> There is also a CSR[2] in need of review.
>
> The spec for the 2-arg and 3-arg Class.forName() methods states they 
> will "locate, load, and link" the class, however the linking part is 
> not ensured to happen.
>
> Although the VM spec allows flexibility WRT when classes are linked, 
> this is a corner where the Class.forName() spec is not being upheld. 
> While this is not an issue for most usages,? 8181144 [3] demonstrates 
> how this can be a problem (with the debugging interface, in this case).
>
> This fix ensures that linking happens during the course of 
> Class.forName().? Class.forName() already @throws LinkageError, so no 
> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
> small spec update, due to calling Class.forName with init=false,
>
> Of course Errors are not required to be caught.? It is therefore 
> possible that the new behavior could introduce previously unseen, 
> possibly unhandled LinkageErrors.? A new VM flag 
> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
> behavior (to keep such code running until it can be updated).
>
> This change surfaced a couple new "A JNI error has occurred" 
> situations (see 8181033[5]) in the Launcher, by way of
> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
> (using the 3-arg Class::forName, detailed in the bug report[4]),
> and
> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
> (using the 2-arg Class::forName).
>
> The Launcher is updated to maintain non-confusing error messages :).
>
> The new test included with this fix ensures that 8181144[3] is 
> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>
> Automated corelibs and hotspot tests pass cleanly.
>
> Thanks,
> -Brent
>
> -- 
> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>
> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>
> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>
> 4. 
> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986
>
> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>

From david.holmes at oracle.com  Thu Sep  5 22:45:10 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Sep 2019 08:45:10 +1000
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <8b91ab12-7e11-6b9c-57ff-1ddb68a478a8@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
 <8b91ab12-7e11-6b9c-57ff-1ddb68a478a8@oracle.com>
Message-ID: <7d1c96e9-31bf-857f-a06e-407c1b2f468b@oracle.com>

Thanks Dan!

David

On 6/09/2019 7:16 am, Daniel D. Daugherty wrote:
> On 9/4/19 5:39 AM, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8230422
>> webrev: http://cr.openjdk.java.net/~dholmes/8230422/webrev/
>>
>> This is mostly a mechanical change from os::sleep to 
>> os::naked_short_sleep or os::naked_sleep, but it affects code in 
>> runtime, jfr, compiler and GC. The patch file is best to use for 
>> review purposes.
> 
> Thumbs up. I used the patch file for everything except for:
> 
>  ??? src/hotspot/share/runtime/os.cpp
> 
> That file needed frames... :-)
> 
> Dan
> 
>>
>> Summary of changes:
>> - added os::naked_sleep as a wrapper around os::naked_short_sleep for 
>> sleeps longer than 1 second** - not usable by JavaThreads
>> - os::sleep now only has the old interruptible path and takes a 
>> JavaThread parameter rather than thread
>> - changed os::sleep(thread,millis,false) to 
>> os::naked_short_sleep(millis) or os::naked_sleep(millis) depending on 
>> the timeout value
>> - changed os::sleep(thread,millis,true) to os::sleep(thread,millis) 
>> with checks/changes where needed to ensure "thread" is a JavaThread
>>
>> ** Many of the calls to this use a VM flag to define the timeout. That 
>> either defaults to 1 or 0 (not used) but is otherwise unconstrained in 
>> value. While sleeps longer than one second don't really make sense I 
>> didn't want to preclude them without there being a range check in 
>> place for the flag itself.
>>
>> Testing: tiers 1- 3
>>
>> I'd appreciate it if someone involved with Shenandoah can check the 
>> one change in that code.
>>
>> Thanks,
>> David
> 

From brent.christian at oracle.com  Fri Sep  6 00:09:19 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 5 Sep 2019 17:09:19 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com>
Message-ID: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com>

Hi, David

On 9/5/19 12:52 AM, David Holmes wrote:
> 
> Good to see this all come together :)

:)

> So to clarify for others any current caller to 
> find_class_from_class_loader that passes true for "init" was already 
> implicitly asking for a linked class (as you must be linked before you 
> can be initialized). With that in mind I would suggest that in 
> find_class_from_class_loader you add an assert:
> 
> ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, 
> jboolean init, jboolean link,
>  ????????????????????????????????????? Handle loader, Handle 
> protection_domain,
>  ????????????????????????????????????? jboolean throwError, TRAPS) {
> +assert((init && link) || !init, "incorrect use of init/link arguments");
> 
> just to ensure the callers understand this.

I'm good with adding an assert to check for coherent arguments.

(Another interpretation is that if 'init' is set, then the 'link' 
argument is ignored, since linking is implied).

> Aside: in looking at this I've spotted another existing bug. JNI 
> FindClass is not specified to perform class initialization, but the 
> implementation passes init=true!

OK, thanks.  I've noted this in JDK-8226540.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> 
> I don't see the need for the new note given it already has
> 
> * @throws LinkageError if the linkage fails

(Discussed in the CSR)

> src/java.base/share/classes/sun/launcher/LauncherHelper.java
> ... > Is AccessControlException the only exception, that is not a
> LinkageError, that might be thrown when linking? I would think a number 
> of others are possible - in particular IllegalAccessError might occur 
> during verification. Other than the fact a test obviously triggered 
> this, it's not clear why ACE should be singled out here. ??

Also discussed in the CSR[1].

> test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java
> 
> 45???? // public static void foo(Foo f) { }
> 
> Unclear why this exists. Also the test refers initially to class Foo but 
> then uses Foo2 and Foo3. ??

I'm guessing it's just a leftover from an earlier version of the test. 
I've removed the comment, and updated the test @summary.

Serguei, anything to add?

>> There is also a CSR[2] in need of review.
> 
> I've added a couple of comments and will add myself as a reviewer once 
> things are near finalized.

Thanks for taking a look.

Updated webrev at:
http://cr.openjdk.java.net/~bchristi/8212117/webrev10/

-Brent

1. 
https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303

>>
>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>> will "locate, load, and link" the class, however the linking part is 
>> not ensured to happen.
>>
>> Although the VM spec allows flexibility WRT when classes are linked, 
>> this is a corner where the Class.forName() spec is not being upheld. 
>> While this is not an issue for most usages,? 8181144 [3] demonstrates 
>> how this can be a problem (with the debugging interface, in this case).
>>
>> This fix ensures that linking happens during the course of 
>> Class.forName().? Class.forName() already @throws LinkageError, so no 
>> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
>> small spec update, due to calling Class.forName with init=false,
>>
>> Of course Errors are not required to be caught.? It is therefore 
>> possible that the new behavior could introduce previously unseen, 
>> possibly unhandled LinkageErrors.? A new VM flag 
>> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
>> behavior (to keep such code running until it can be updated).
>>
>> This change surfaced a couple new "A JNI error has occurred" 
>> situations (see 8181033[5]) in the Launcher, by way of
>> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>> and
>> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>> (using the 2-arg Class::forName).
>>
>> The Launcher is updated to maintain non-confusing error messages :).
>>
>> The new test included with this fix ensures that 8181144[3] is 
>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>
>> Automated corelibs and hotspot tests pass cleanly.
>>
>> Thanks,
>> -Brent
>>
>> -- 
>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>
>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>
>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>
>> 4. 
>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>
>>
>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>

From brent.christian at oracle.com  Fri Sep  6 00:09:29 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 5 Sep 2019 17:09:29 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>
Message-ID: <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com>

Hi, Joe

@jls tags added (and as long as we're in Class.java, I added @jls to the 
3-arg Class.forName(), which has an equivalent paragraph).

Updated webrev:
http://cr.openjdk.java.net/~bchristi/8212117/webrev10/

Thanks,
-Brent

On 9/5/19 3:30 PM, Joe Darcy wrote:
> Hello,
> 
> For the doc changes in MethodHandle, please supplement the paragraph
> 
> 1937????????? * <p>
> 1938????????? * Note that this method throws errors related to loading 
> and linking as
> 1939????????? * specified in Sections 12.2 and 12.3 of <em>The Java 
> Language
> 1940????????? * Specification</em>.
> 
> with @jls tags like
> 
> @jls 12.2 Loading of Classes and Interfaces
> @jsl 12.3 Linking of Classes and Interfaces
> 
> as done elsewhere in the base module. I think it would be slightly 
> better to remove the section numbers from the main text but keep them in 
> the @jls tags since it is now possible to check that the listed name of 
> the section matches what is in the JLS.
> 
> Thanks,
> 
> -Joe
> 
> 
> On 9/4/2019 2:12 PM, Brent Christian wrote:
>> Hi,
>>
>> Please review my fix for JDK-8212117[1].? The webrev is here:
>>
>> http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
>>
>> There is also a CSR[2] in need of review.
>>
>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>> will "locate, load, and link" the class, however the linking part is 
>> not ensured to happen.
>>
>> Although the VM spec allows flexibility WRT when classes are linked, 
>> this is a corner where the Class.forName() spec is not being upheld. 
>> While this is not an issue for most usages,? 8181144 [3] demonstrates 
>> how this can be a problem (with the debugging interface, in this case).
>>
>> This fix ensures that linking happens during the course of 
>> Class.forName().? Class.forName() already @throws LinkageError, so no 
>> spec change is needed there. MethodHandles.Lookup.findClass() needs a 
>> small spec update, due to calling Class.forName with init=false,
>>
>> Of course Errors are not required to be caught.? It is therefore 
>> possible that the new behavior could introduce previously unseen, 
>> possibly unhandled LinkageErrors.? A new VM flag 
>> (-XX:+ClassForNameDeferLinking) is introduced to restore the previous 
>> behavior (to keep such code running until it can be updated).
>>
>> This change surfaced a couple new "A JNI error has occurred" 
>> situations (see 8181033[5]) in the Launcher, by way of
>> ? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>> and
>> ? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>> (using the 2-arg Class::forName).
>>
>> The Launcher is updated to maintain non-confusing error messages :).
>>
>> The new test included with this fix ensures that 8181144[3] is 
>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>
>> Automated corelibs and hotspot tests pass cleanly.
>>
>> Thanks,
>> -Brent
>>
>> -- 
>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>
>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>
>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>
>> 4. 
>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>
>>
>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>

From serguei.spitsyn at oracle.com  Fri Sep  6 00:25:12 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 5 Sep 2019 17:25:12 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com>
 <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com>
Message-ID: <2fe54043-df9e-4a21-bf3a-4aad7b5cb76d@oracle.com>

Hi Brent,

Some quick reply below.


On 9/5/19 5:09 PM, Brent Christian wrote:
> Hi, David
>
> On 9/5/19 12:52 AM, David Holmes wrote:
>>
>> Good to see this all come together :)
>
> :)
>
>> So to clarify for others any current caller to 
>> find_class_from_class_loader that passes true for "init" was already 
>> implicitly asking for a linked class (as you must be linked before 
>> you can be initialized). With that in mind I would suggest that in 
>> find_class_from_class_loader you add an assert:
>>
>> ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, 
>> jboolean init, jboolean link,
>> ?????????????????????????????????????? Handle loader, Handle 
>> protection_domain,
>> ?????????????????????????????????????? jboolean throwError, TRAPS) {
>> +assert((init && link) || !init, "incorrect use of init/link 
>> arguments");
>>
>> just to ensure the callers understand this.
>
> I'm good with adding an assert to check for coherent arguments.
>
> (Another interpretation is that if 'init' is set, then the 'link' 
> argument is ignored, since linking is implied).
>
>> Aside: in looking at this I've spotted another existing bug. JNI 
>> FindClass is not specified to perform class initialization, but the 
>> implementation passes init=true!
>
> OK, thanks.? I've noted this in JDK-8226540.
>
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>
>> I don't see the need for the new note given it already has
>>
>> * @throws LinkageError if the linkage fails
>
> (Discussed in the CSR)
>
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java
>> ... > Is AccessControlException the only exception, that is not a
>> LinkageError, that might be thrown when linking? I would think a 
>> number of others are possible - in particular IllegalAccessError 
>> might occur during verification. Other than the fact a test obviously 
>> triggered this, it's not clear why ACE should be singled out here. ??
>
> Also discussed in the CSR[1].
>
>> test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java
>>
>> 45???? // public static void foo(Foo f) { }
>>
>> Unclear why this exists. Also the test refers initially to class Foo 
>> but then uses Foo2 and Foo3. ??
>
> I'm guessing it's just a leftover from an earlier version of the test. 
> I've removed the comment, and updated the test @summary.

Yes, it is just a left over from earlier version of the test.

> Serguei, anything to add?

I'm happy this test got used and included into the webrev, thanks!

>>> There is also a CSR[2] in need of review.
>>
>> I've added a couple of comments and will add myself as a reviewer 
>> once things are near finalized.
>
> Thanks for taking a look.
>
> Updated webrev at:
> http://cr.openjdk.java.net/~bchristi/8212117/webrev10/

Will look at the webrev soon.

Thanks,
serguei

> -Brent
>
> 1. 
> https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303
>
>>>
>>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>>> will "locate, load, and link" the class, however the linking part is 
>>> not ensured to happen.
>>>
>>> Although the VM spec allows flexibility WRT when classes are linked, 
>>> this is a corner where the Class.forName() spec is not being upheld. 
>>> While this is not an issue for most usages, 8181144 [3] demonstrates 
>>> how this can be a problem (with the debugging interface, in this case).
>>>
>>> This fix ensures that linking happens during the course of 
>>> Class.forName().? Class.forName() already @throws LinkageError, so 
>>> no spec change is needed there. MethodHandles.Lookup.findClass() 
>>> needs a small spec update, due to calling Class.forName with 
>>> init=false,
>>>
>>> Of course Errors are not required to be caught.? It is therefore 
>>> possible that the new behavior could introduce previously unseen, 
>>> possibly unhandled LinkageErrors.? A new VM flag 
>>> (-XX:+ClassForNameDeferLinking) is introduced to restore the 
>>> previous behavior (to keep such code running until it can be updated).
>>>
>>> This change surfaced a couple new "A JNI error has occurred" 
>>> situations (see 8181033[5]) in the Launcher, by way of
>>> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>>> and
>>> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>>> (using the 2-arg Class::forName).
>>>
>>> The Launcher is updated to maintain non-confusing error messages :).
>>>
>>> The new test included with this fix ensures that 8181144[3] is 
>>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>>
>>> Automated corelibs and hotspot tests pass cleanly.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> -- 
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>>
>>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>>
>>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>>
>>> 4. 
>>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>>
>>>
>>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>>


From mandy.chung at oracle.com  Fri Sep  6 00:26:35 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 5 Sep 2019 17:26:35 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
Message-ID: <4b9974c9-3782-1558-9027-92b38ba1485b@oracle.com>

On 9/4/19 2:12 PM, Brent Christian wrote:
>
>
> There is also a CSR[2] in need of review.

The javadoc for Lookup::findClass:

"In particular, the method first attempts to load the requested class"

I think this sentence is no longer needed together with your change.? 
What about:

          /**
-         * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static
-         * initializer of the class is not run.
+         * Looks up a class by name from the lookup context defined by this {@code Lookup} object.
+         * This method attempts to locate, load, and link the class, and then determines whether
+         * the class is accessible to this {@code Lookup} object.
+         * The static initializer of the class is not run.
           * <p>
           * The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class
-         * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to
-         * load the requested class, and then determines whether the class is accessible to this lookup object.
+         * loader, and the {@linkplain #lookupModes() lookup modes}.


The note you added in this method should also be added to 2-arg 
Class::forName for consistency.

We should add @jls as Joe suggests.

Mandy


From mandy.chung at oracle.com  Fri Sep  6 01:03:40 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 5 Sep 2019 18:03:40 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>
 <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com>
Message-ID: <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com>



On 9/5/19 5:09 PM, Brent Christian wrote:
> Updated webrev:
> http://cr.openjdk.java.net/~bchristi/8212117/webrev10/

jvm.h

  349  * Link the 'arg' class (unless ClassForNameDeferLinking is set)

I suggest to drop "(unless ...)" phrase because the flag is temporary.

jni.cpp

The implementation of JNI FindClass has the same behavior as 1-arg
Class.forName(name).  The JNI spec needs fixing but it's a separate
issue.

find_class_from_class_loader
   I like David's suggestion to assert that if init == true, link
   must be true.  Alternatively, pass an enum instead of two booleans
   clearly tell linking or initializing.

Lookup::findClass:

"In particular, the method first attempts to load the requested class"

I think this sentence is no longer needed together with your change.  What about:

          /**
-         * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static
-         * initializer of the class is not run.
+         * Looks up a class by name from the lookup context defined by this {@code Lookup} object.
+         * This method attempts to locate, load, and link the class, and then determines whether
+         * the class is accessible to this {@code Lookup} object.
+         * The static initializer of the class is not run.
           * <p>
           * The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class
-         * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to
-         * load the requested class, and then determines whether the class is accessible to this lookup object.
+         * loader, and the {@linkplain #lookupModes() lookup modes}.


The note you added in this method should also be added to 2-arg
Class::forName for consistency.

Otherwise, the fix looks good.

Mandy


From glaubitz at physik.fu-berlin.de  Fri Sep  6 11:04:03 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 13:04:03 +0200
Subject: Server JVM fails to build on linux-sparc64 after recent changes
Message-ID: <cf971ed1-7909-b516-2147-d16d7c073108@physik.fu-berlin.de>

Hi!

Has anyone seen this before? I assume there have been made some changes for the
SPARC code that were not considering the necessary changes for Linux as well.

I will bisect this later, but maybe someone already knows what the problem is.

Adrian

=== Output from failing command(s) repeated here ===
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_abstractInterpreter_sparc.o:\n"
* For target hotspot_variant-server_libjvm_objs_abstractInterpreter_sparc.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_abstractInterpreter_sparc.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from /home/glaubitz/jdk/src/hotspot/share/code/compiledMethod.inline.hpp:29,
                  from /home/glaubitz/jdk/src/hotspot/share/runtime/frame.inline.hpp:28,
                  from /home/glaubitz/jdk/src/hotspot/cpu/sparc/abstractInterpreter_sparc.cpp:30:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_abstractInterpreter_sparc.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
    ... (rest of output omitted)
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc.cpp:29:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_clone.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_clone.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_clone.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_expand.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_expand.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_expand.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_format.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_format.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_format.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_gen.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_gen.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_gen.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_misc.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_misc.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_misc.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_peephole.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_peephole.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o:\n"
* For target hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o:
(/bin/grep -v -e "^Note: including file:" <  /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log || true) | /usr/bin/head -n 15
In file included from /home/glaubitz/jdk/src/hotspot/share/code/nativeInst.hpp:30,
                  from ad_sparc.hpp:33,
                  from ad_sparc_pipeline.cpp:28:
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:347:22: error: friend declaration of ?NativeCall* nativeCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   347 |   friend NativeCall* nativeCall_overwriting_at(address instr, address destination = NULL) {
       |                      ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:317:20: note: previous declaration of ?NativeCall* nativeCall_overwriting_at(address, address)?
   317 | inline NativeCall* nativeCall_overwriting_at(address instr,
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:455:32: error: friend declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)? specifies default arguments and isn?t the only declaration [-fpermissive]
   455 |   friend inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination = NULL) {
       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glaubitz/jdk/src/hotspot/cpu/sparc/nativeInst_sparc.hpp:416:23: note: previous declaration of ?NativeFarCall* nativeFarCall_overwriting_at(address, address)?
   416 | inline NativeFarCall* nativeFarCall_overwriting_at(address instr, address destination);
       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
if test `/usr/bin/wc -l < /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_ad_sparc_pipeline.o.log` -gt 15; then /bin/echo "   ... (rest of output omitted)" ; fi
/usr/bin/printf "\n* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n"

* All command lines available in /home/glaubitz/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.
/usr/bin/printf "=== End of repeated output ===\n"
=== End of repeated output ===

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From shade at redhat.com  Fri Sep  6 11:16:04 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Sep 2019 13:16:04 +0200
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
Message-ID: <10c3684f-f59f-9093-4506-63b44632d8f7@redhat.com>

On 9/4/19 11:39 AM, David Holmes wrote:
> I'd appreciate it if someone involved with Shenandoah can check the one change in that code.

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp:
-    os::sleep(Thread::current(), cur, true);
+    os::sleep(JavaThread::current(), cur);

Since os::sleep keeps participating in safepoints ("interruptible = true") after this change, this
is fine.

-- 
Thanks,
-Aleksey


From glaubitz at physik.fu-berlin.de  Fri Sep  6 11:56:15 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 13:56:15 +0200
Subject: Server JVM fails to build on linux-sparc64 after recent changes
In-Reply-To: <cf971ed1-7909-b516-2147-d16d7c073108@physik.fu-berlin.de>
References: <cf971ed1-7909-b516-2147-d16d7c073108@physik.fu-berlin.de>
Message-ID: <74927cb6-9550-6cad-415e-c36670134a77@physik.fu-berlin.de>

Hi!

On 9/6/19 1:04 PM, John Paul Adrian Glaubitz wrote:
> Has anyone seen this before? I assume there have been made some changes for the
> SPARC code that were not considering the necessary changes for Linux as well.
> 
> I will bisect this later, but maybe someone already knows what the problem is.

It looks like a new warning that was introduced with gcc-9. I have opened a bug
report and already have a patch that fixes the problem. Will send an RFR later.

Adrian

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

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From glaubitz at physik.fu-berlin.de  Fri Sep  6 12:26:35 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 14:26:35 +0200
Subject: Is cr.java.openjdk.net down
Message-ID: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>

Hi!

I just tried to upload a webrev to fix 8230708 but the connection timed out:

glaubitz at z6:..incoming/jdk> scp -r 8230708 cr.java.openjdk.net:
ssh: connect to host cr.java.openjdk.net port 22: Connection timed out
lost connection
glaubitz at z6:..incoming/jdk>

Anyone knows whether there are server issues?

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Fri Sep  6 12:42:28 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Sep 2019 22:42:28 +1000
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <10c3684f-f59f-9093-4506-63b44632d8f7@redhat.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
 <10c3684f-f59f-9093-4506-63b44632d8f7@redhat.com>
Message-ID: <4a32c04c-270f-337e-2557-06af6ae6a457@oracle.com>

On 6/09/2019 9:16 pm, Aleksey Shipilev wrote:
> On 9/4/19 11:39 AM, David Holmes wrote:
>> I'd appreciate it if someone involved with Shenandoah can check the one change in that code.
> 
> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp:
> -    os::sleep(Thread::current(), cur, true);
> +    os::sleep(JavaThread::current(), cur);
> 
> Since os::sleep keeps participating in safepoints ("interruptible = true") after this change, this
> is fine.

Thanks Aleksey! My only concern here was whether the code was obviously 
always executed by a JavaThread (even though the interruptible=true 
implies that).

Cheers,
David


From david.holmes at oracle.com  Fri Sep  6 12:45:30 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Sep 2019 22:45:30 +1000
Subject: Server JVM fails to build on linux-sparc64 after recent changes
In-Reply-To: <74927cb6-9550-6cad-415e-c36670134a77@physik.fu-berlin.de>
References: <cf971ed1-7909-b516-2147-d16d7c073108@physik.fu-berlin.de>
 <74927cb6-9550-6cad-415e-c36670134a77@physik.fu-berlin.de>
Message-ID: <58f1ca5b-2eeb-5cbe-70a4-911155274539@oracle.com>

Hi Adrian,

On 6/09/2019 9:56 pm, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 9/6/19 1:04 PM, John Paul Adrian Glaubitz wrote:
>> Has anyone seen this before? I assume there have been made some 
>> changes for the
>> SPARC code that were not considering the necessary changes for Linux 
>> as well.
>>
>> I will bisect this later, but maybe someone already knows what the 
>> problem is.
> 
> It looks like a new warning that was introduced with gcc-9. I have 
> opened a bug
> report and already have a patch that fixes the problem. Will send an RFR 
> later.

I was going to ask if you'd used gcc-9 previously because 
nativeInst_sparc.hpp hasn't been touched in 7 months :)

Cheers,
David

> Adrian
> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8230708
> 

From david.holmes at oracle.com  Fri Sep  6 12:50:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Sep 2019 22:50:41 +1000
Subject: Is cr.java.openjdk.net down
In-Reply-To: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
References: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
Message-ID: <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>

No problems from my location.

David

On 6/09/2019 10:26 pm, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I just tried to upload a webrev to fix 8230708 but the connection timed 
> out:
> 
> glaubitz at z6:..incoming/jdk> scp -r 8230708 cr.java.openjdk.net:
> ssh: connect to host cr.java.openjdk.net port 22: Connection timed out
> lost connection
> glaubitz at z6:..incoming/jdk>
> 
> Anyone knows whether there are server issues?
> 
> Adrian
> 

From coleen.phillimore at oracle.com  Fri Sep  6 13:15:58 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 6 Sep 2019 09:15:58 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
Message-ID: <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>


Can you send a webrev of the final version of this change?
thanks,
Coleen


On 9/4/19 10:44 AM, Leo Korinth wrote:
>
>
> On 04/09/2019 15:51, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/4/19 7:16 AM, Leo Korinth wrote:
>>>
>>>
>>> On 03/09/2019 20:07, Kim Barrett wrote:
>>>>> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
>>>>> On 9/3/19 12:12 PM, Leo Korinth wrote:
>>>>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert 
>>>>>> one usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to 
>>>>>> be able to also be an array type when allocated in another place.
>>>>>
>>>>> [?]? But I don't agree.? I don't think NEW_C_HEAP_ARRAY should be 
>>>>> used to allocate and FREE_C_HEAP_OBJ should be used to deallocate. 
>>>>> That's worse.
>>>>
>>>> That wasn?t what was suggested.? The suggestion was to always be 
>>>> consistent with the pairing,
>>>> e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or 
>>>> use NEW_C_HEAP_OBJ
>>>> and FREE_C_HEAP_OBJ, but never mix the pairings for a given object. 
>>>> I think that?s what the
>>>> updated change is doing.
>>>
>>> That was what I tried to do, your explanation is much better than 
>>> mine, thanks Kim.
>>>>
>>>>> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should 
>>>>> exist.? They should just use new Type(), where Type is inherited 
>>>>> from CHeapObj<mtAppropriate>
>>> It is my goal to remove /all/ allocation macros, but I could not fit 
>>> it into this change ;-)
>>
>> How are you going to remove the NEW_C_HEAP_ARRAY macros?? Is that 
>> somewhere in this thread?? Everything got cut off.? Can you put all 
>> this in the CR?
>
> I am looking into replacing them with operator new, but I would like 
> to see that I have a working sane version before proposing anything.
>
> It is not related to this in any way. I feel these changes improve the 
> current situation, even though NEW_C_HEAP_OBJ might not be the best 
> solution, it is still /better/ than faking allocation of an array. I 
> also believe it is better to remove bad usage before it is copied than 
> doing nothing because the improvement is not perfect.
>
>> What is the latest version of this patch?
>
> I have no working code for removing those macros, but I am looking 
> into it. Hopefully it will work, but lets not waste time on my ideas.
>
> Thanks,
> Leo
>
>>
>> Thanks,
>> Coleen
>>
>>
>>>
>>> Thanks, Leo
>>>>
>>>> I was expecting that to have widespread impact, but it seems there 
>>>> are far fewer uses of NEW_C_HEAP_OBJ
>>>> than I was expecting.? But I suggest that doing anything about that 
>>>> is out of scope for this change.
>>>>
>>>> I?m also not really fond of the allocation base class approach; 
>>>> C++11 allows some alternatives.
>>>>
>>


From glaubitz at physik.fu-berlin.de  Fri Sep  6 13:21:16 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 15:21:16 +0200
Subject: Server JVM fails to build on linux-sparc64 after recent changes
In-Reply-To: <58f1ca5b-2eeb-5cbe-70a4-911155274539@oracle.com>
References: <cf971ed1-7909-b516-2147-d16d7c073108@physik.fu-berlin.de>
 <74927cb6-9550-6cad-415e-c36670134a77@physik.fu-berlin.de>
 <58f1ca5b-2eeb-5cbe-70a4-911155274539@oracle.com>
Message-ID: <0732ae9a-bc3b-7a62-5f52-64e389fbc173@physik.fu-berlin.de>

On 9/6/19 2:45 PM, David Holmes wrote:
>> On 9/6/19 1:04 PM, John Paul Adrian Glaubitz wrote:
>>> Has anyone seen this before? I assume there have been made some changes for the
>>> SPARC code that were not considering the necessary changes for Linux as well.
>>>
>>> I will bisect this later, but maybe someone already knows what the problem is.
>>
>> It looks like a new warning that was introduced with gcc-9. I have opened a bug
>> report and already have a patch that fixes the problem. Will send an RFR later.
> 
> I was going to ask if you'd used gcc-9 previously because nativeInst_sparc.hpp hasn't been touched in 7 months :)

Debian recently switched the default compiler for the openjdk packages over to gcc-9,
so it was obvious very quickly where the problem was ;).

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From glaubitz at physik.fu-berlin.de  Fri Sep  6 13:22:20 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 15:22:20 +0200
Subject: Is cr.java.openjdk.net down
In-Reply-To: <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>
References: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
 <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>
Message-ID: <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>

On 9/6/19 2:50 PM, David Holmes wrote:
> No problems from my location.

I can access the website over the browser, but SSH doesn't work.

Can you try to verify SSH works for you or has the mechanism for uploading
webrevs been changed recently?

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From glaubitz at physik.fu-berlin.de  Fri Sep  6 13:29:47 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 15:29:47 +0200
Subject: Is cr.java.openjdk.net down
In-Reply-To: <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>
References: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
 <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>
 <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>
Message-ID: <6ddb820e-678d-c7d9-9e61-9a9c35f91064@physik.fu-berlin.de>

On 9/6/19 3:22 PM, John Paul Adrian Glaubitz wrote:
> On 9/6/19 2:50 PM, David Holmes wrote:
>> No problems from my location.
> 
> I can access the website over the browser, but SSH doesn't work.
> 
> Can you try to verify SSH works for you or has the mechanism for uploading
> webrevs been changed recently?

Never mind. I typed cr.java.openjdk.net instead of cr.openjdk.java.net ;).

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From daniel.daugherty at oracle.com  Fri Sep  6 13:29:54 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 6 Sep 2019 09:29:54 -0400
Subject: Is cr.java.openjdk.net down
In-Reply-To: <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>
References: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
 <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>
 <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>
Message-ID: <4e3e9fb2-b0e0-f6fc-135c-71615aba3f65@oracle.com>

On 9/6/19 9:22 AM, John Paul Adrian Glaubitz wrote:
> On 9/6/19 2:50 PM, David Holmes wrote:
>> No problems from my location.
>
> I can access the website over the browser, but SSH doesn't work.
>
> Can you try to verify SSH works for you or has the mechanism for 
> uploading
> webrevs been changed recently?

ssh into cr.openjdk.java.net has never worked. You can use scp or sftp...

Dan

>
> Adrian
>


From glaubitz at physik.fu-berlin.de  Fri Sep  6 13:32:25 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 6 Sep 2019 15:32:25 +0200
Subject: RFR: 8230708: Linux-sparc fails to build with gcc-9
Message-ID: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>

Hello!

Please review this small change [1] which fixes the build on Linux-sparc
with gcc-9 as the default C/C++ compiler [2].

Cheers,
Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8230708/webrev.01/
> [2] https://bugs.openjdk.java.net/browse/JDK-8230708

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From shade at redhat.com  Fri Sep  6 13:33:45 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Sep 2019 15:33:45 +0200
Subject: RFR(S): 8230422: Convert uninterruptible os::sleep calls to
 os::naked_short_sleep
In-Reply-To: <4a32c04c-270f-337e-2557-06af6ae6a457@oracle.com>
References: <315e1661-9ff0-afd4-ffc7-c2ccc2bb5cfd@oracle.com>
 <10c3684f-f59f-9093-4506-63b44632d8f7@redhat.com>
 <4a32c04c-270f-337e-2557-06af6ae6a457@oracle.com>
Message-ID: <4c21cfac-5102-e124-82fa-8bcdf378e7b4@redhat.com>

On 9/6/19 2:42 PM, David Holmes wrote:
> On 6/09/2019 9:16 pm, Aleksey Shipilev wrote:
>> On 9/4/19 11:39 AM, David Holmes wrote:
>>> I'd appreciate it if someone involved with Shenandoah can check the one change in that code.
>>
>> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp:
>> -??? os::sleep(Thread::current(), cur, true);
>> +??? os::sleep(JavaThread::current(), cur);
>>
>> Since os::sleep keeps participating in safepoints ("interruptible = true") after this change, this
>> is fine.
> 
> Thanks Aleksey! My only concern here was whether the code was obviously always executed by a
> JavaThread (even though the interruptible=true implies that).

Yes, pacer should be called only on JavaThread (mutator) allocation path. If not, that's the problem
with Shenandoah, and should be fixed there. The patch passes at least hotspot_gc_shenandoah, so
there is no evidence anything dodgy is happening there yet.

-- 
Thanks,
-Aleksey


From daniel.daugherty at oracle.com  Fri Sep  6 13:33:52 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 6 Sep 2019 09:33:52 -0400
Subject: Is cr.java.openjdk.net down
In-Reply-To: <6ddb820e-678d-c7d9-9e61-9a9c35f91064@physik.fu-berlin.de>
References: <dd74c094-eaff-6871-41bd-60328b889bb5@physik.fu-berlin.de>
 <6e16983c-e80d-3bb1-7f2e-7915e4ce4b47@oracle.com>
 <d60d8976-0265-2dc3-01bd-b3f4643681cd@physik.fu-berlin.de>
 <6ddb820e-678d-c7d9-9e61-9a9c35f91064@physik.fu-berlin.de>
Message-ID: <c279ebc6-ef44-0dff-bfb9-a0893c53c659@oracle.com>

On 9/6/19 9:29 AM, John Paul Adrian Glaubitz wrote:
> On 9/6/19 3:22 PM, John Paul Adrian Glaubitz wrote:
>> On 9/6/19 2:50 PM, David Holmes wrote:
>>> No problems from my location.
>>
>> I can access the website over the browser, but SSH doesn't work.
>>
>> Can you try to verify SSH works for you or has the mechanism for 
>> uploading
>> webrevs been changed recently?
>
> Never mind. I typed cr.java.openjdk.net instead of cr.openjdk.java.net 
> ;).
>
> Adrian

Oops... should have noticed the typo in the subject line...

Dan

From hohensee at amazon.com  Fri Sep  6 18:20:01 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 6 Sep 2019 18:20:01 +0000
Subject: 8230708: Linux-sparc fails to build with gcc-9
In-Reply-To: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
References: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
Message-ID: <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>

Looks good.

Paul

?On 9/6/19, 6:35 AM, "hotspot-dev on behalf of John Paul Adrian Glaubitz" <hotspot-dev-bounces at openjdk.java.net on behalf of glaubitz at physik.fu-berlin.de> wrote:

    Hello!
    
    Please review this small change [1] which fixes the build on Linux-sparc
    with gcc-9 as the default C/C++ compiler [2].
    
    Cheers,
    Adrian
    
    > [1] http://cr.openjdk.java.net/~glaubitz/8230708/webrev.01/
    > [2] https://bugs.openjdk.java.net/browse/JDK-8230708
    
    -- 
      .''`.  John Paul Adrian Glaubitz
    : :' :  Debian Developer - glaubitz at debian.org
    `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
       `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
    
    


From brent.christian at oracle.com  Fri Sep  6 21:20:01 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 6 Sep 2019 14:20:01 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>
 <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com>
 <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com>
Message-ID: <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com>

Hi, Mandy

On 9/5/19 6:03 PM, Mandy Chung wrote:
> On 9/5/19 5:09 PM, Brent Christian wrote:
> 
> jvm.h
> 
>   349  * Link the 'arg' class (unless ClassForNameDeferLinking is set)
> 
> I suggest to drop "(unless ...)" phrase because the flag is temporary.

Sure, good idea.

> jni.cpp
> 
> The implementation of JNI FindClass has the same behavior as 1-arg
> Class.forName(name).  The JNI spec needs fixing but it's a separate
> issue.

Right - looks like David filed JDK-8230685.

> find_class_from_class_loader
>    I like David's suggestion to assert that if init == true, link
>    must be true.  Alternatively, pass an enum instead of two booleans
>    clearly tell linking or initializing.

Yup, assert added.

> Lookup::findClass:
> 
> "In particular, the method first attempts to load the requested class"
> 
> I think this sentence is no longer needed together with your change.  What about:
> 
>           /**
> -         * Looks up a class by name from the lookup context defined by this {@code Lookup} object. The static
> -         * initializer of the class is not run.
> +         * Looks up a class by name from the lookup context defined by this {@code Lookup} object.
> +         * This method attempts to locate, load, and link the class, and then determines whether
> +         * the class is accessible to this {@code Lookup} object.
> +         * The static initializer of the class is not run.
>            * <p>
>            * The lookup context here is determined by the {@linkplain #lookupClass() lookup class}, its class
> -         * loader, and the {@linkplain #lookupModes() lookup modes}. In particular, the method first attempts to
> -         * load the requested class, and then determines whether the class is accessible to this lookup object.
> +         * loader, and the {@linkplain #lookupModes() lookup modes}.

Looks good to me.

> The note you added in this method should also be added to 2-arg
> Class::forName for consistency.

OK, sure.


Update webrev is here:
   http://cr.openjdk.java.net/~bchristi/8212117/webrev11/
with changes to jvm.h, MethodHandles.java, and Class.java.

I went ahead and put together a specdiff[1] for the changed methods 
([2][3][4]).  I've updated and finalized the CSR.

Thanks for the review,
-Brent

1. 
http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/specdiff-summary.html

2. 
http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/Class-report.html#forName(java.lang.String,boolean,java.lang.ClassLoader)

3. 
http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/Class-report.html#forName(java.lang.Module,java.lang.String)

4. 
http://cr.openjdk.java.net/~bchristi/8212117/webrev11-specdiff/invoke/MethodHandles.Lookup-report.html#findClass(java.lang.String)

From mandy.chung at oracle.com  Fri Sep  6 21:30:00 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 6 Sep 2019 14:30:00 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <40495d79-fa13-2f98-0fb9-8ef5a44bab6c@oracle.com>
 <436955a8-0145-c7f1-95d0-b71b1d228b11@oracle.com>
 <7cd5ca60-9532-fdd7-5baa-39b4a88e5015@oracle.com>
 <59f97847-6da5-1828-4678-47629c1d4fdf@oracle.com>
Message-ID: <b205fa27-ae63-efbb-769a-bf34f4add863@oracle.com>

On 9/6/19 2:20 PM, Brent Christian wrote:
> Update webrev is here:
> http://cr.openjdk.java.net/~bchristi/8212117/webrev11/
> with changes to jvm.h, MethodHandles.java, and Class.java.

Looks good.

Mandy

From glaubitz at physik.fu-berlin.de  Fri Sep  6 22:44:49 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 7 Sep 2019 00:44:49 +0200
Subject: Zero crashing on Linux-sparc with gcc-9
Message-ID: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>

Hi!

In addition to the build failure of the server VM with gcc-9, Zero is affected as
well, but here it's not a syntax issue but the VM is segfaulting when built with
gcc-9.

Backtrace is below. Any suggestions?

Adrian

glaubitz at gcc202:~/jdk$ gdb ./build/linux-sparcv9-zero-release/jdk/bin/java
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/linux-sparcv9-zero-release/jdk/bin/java...
(No debugging symbols found in ./build/linux-sparcv9-zero-release/jdk/bin/java)
(gdb) r
Starting program: /home/glaubitz/jdk/build/linux-sparcv9-zero-release/jdk/bin/java
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".
[New Thread 0xfff800010137f900 (LWP 128093)]

Thread 2 "java" received signal SIGBUS, Bus error.
[Switching to Thread 0xfff800010137f900 (LWP 128093)]
0xfff8000100c5d0d4 in SharedRuntime::generate_stubs () at /home/glaubitz/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:107
107       _resolve_static_call_blob            = generate_resolve_blob(CAST_FROM_FN_PTR(address, SharedRuntime::resolve_static_call_C),        "resolve_static_call");
(gdb) bt
#0  0xfff8000100c5d0d4 in SharedRuntime::generate_stubs () at /home/glaubitz/jdk/src/hotspot/share/runtime/sharedRuntime.cpp:107
#1  0xfff8000100a3d688 in init_globals () at /home/glaubitz/jdk/src/hotspot/share/runtime/init.cpp:131
#2  0xfff8000100cab8bc in Threads::create_vm (args=<optimized out>, canTryAgain=0xfff800010137eb8f) at /home/glaubitz/jdk/src/hotspot/share/runtime/thread.cpp:3773
#3  0xfff8000100a7f1e4 in JNI_CreateJavaVM_inner (args=0xfff800010137ecb8, penv=0xfff800010137ecb0, vm=0xfff800010137eca8) at /home/glaubitz/jdk/src/hotspot/share/prims/jni.cpp:3934
#4  JNI_CreateJavaVM (vm=0xfff800010137eca8, penv=0xfff800010137ecb0, args=0xfff800010137ecb8) at /home/glaubitz/jdk/src/hotspot/share/prims/jni.cpp:4017
#5  0xfff800010024bac8 in InitializeJVM (ifn=<synthetic pointer>, penv=0xfff800010137ecb0, pvm=0xfff800010137eca8) at /home/glaubitz/jdk/src/java.base/share/native/libjli/java.c:1539
#6  JavaMain (_args=<optimized out>) at /home/glaubitz/jdk/src/java.base/share/native/libjli/java.c:417
#7  0xfff8000100250e74 in ThreadJavaMain (args=0x7feffffa8f0) at /home/glaubitz/jdk/src/java.base/unix/native/libjli/java_md_solinux.c:740
#8  0xfff8000100363e68 in start_thread (arg=0xfff800010137f900) at pthread_create.c:486
#9  0xfff800010067032c in __thread_start () at ../sysdeps/unix/sysv/linux/sparc/sparc64/clone.S:78
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Mon Sep  9 05:21:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Sep 2019 15:21:50 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
Message-ID: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8230423
webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/

This is the next step in the sleep/interrupt support code reshuffle. Now 
that os::sleep is platform independent and only applicable to 
JavaThreads, we can move it to JavaThread as an instance method.

Summary of changes:
- os::sleep moved to JavaThread::sleep as instance method
- signature changed to return bool - true means timed-out; false means 
interrupted
- rearranged the sleep code slightly to remove the initial back-to-back 
nanoTime() calls - as suggested by Roger.
- _SleepEvent moved from Thread to JavaThread
- minor changes to os::interrupt to account for move to JavaThread (this 
code will also be moved to JavaThread in the next fix)
- call sites changed from os::sleep(t,ms) to t->sleep(ms)

Testing:
  - tiers 1-3

Thanks,
David

From leo.korinth at oracle.com  Mon Sep  9 08:35:33 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Mon, 9 Sep 2019 10:35:33 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
 <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
Message-ID: <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>



On 06/09/2019 15:15, coleen.phillimore at oracle.com wrote:
> 
> Can you send a webrev of the final version of this change?
> thanks,
> Coleen
> 
> 

I am unsure if this is the final version; I have not got an answer on my 
two suggestions. This is the one I prefer:

Incremental:
http://cr.openjdk.java.net/~lkorinth/8227168/01_02/

Full:
http://cr.openjdk.java.net/~lkorinth/8227168/02/

Testing:
Only comments added, no new testing.

Thanks,
Leo

From robbin.ehn at oracle.com  Mon Sep  9 08:38:01 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 9 Sep 2019 10:38:01 +0200
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
Message-ID: <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>

Hi David,

3598 void os::interrupt(Thread* thread) {
3599   debug_only(Thread::check_for_dangling_thread_pointer(thread);)
3600   assert(thread->is_Java_thread(), "invariant");
3601   JavaThread* jt = (JavaThread*) thread;

Why not change the argument type to JavaThread* ?

Thanks, Robbin

On 9/9/19 7:21 AM, David Holmes wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
> 
> This is the next step in the sleep/interrupt support code reshuffle. Now that 
> os::sleep is platform independent and only applicable to JavaThreads, we can 
> move it to JavaThread as an instance method.
> 
> Summary of changes:
> - os::sleep moved to JavaThread::sleep as instance method
> - signature changed to return bool - true means timed-out; false means interrupted
> - rearranged the sleep code slightly to remove the initial back-to-back 
> nanoTime() calls - as suggested by Roger.
> - _SleepEvent moved from Thread to JavaThread
> - minor changes to os::interrupt to account for move to JavaThread (this code 
> will also be moved to JavaThread in the next fix)
> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
> 
> Testing:
>  ?- tiers 1-3
> 
> Thanks,
> David

From stefan.johansson at oracle.com  Mon Sep  9 08:38:54 2019
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Mon, 9 Sep 2019 10:38:54 +0200
Subject: RFR: 8230562: Remove g1HeapSizingPolicy_ext.cpp
In-Reply-To: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
References: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
Message-ID: <E40ADCEE-96C8-4179-A331-F336CBC9F2A2@oracle.com>

Hi Stefan,

> 4 sep. 2019 kl. 13:23 skrev Stefan Karlsson <stefan.karlsson at oracle.com>:
> 
> Hi all,
> 
> Please review this patch to remove g1HeapSizingPolicy_ext.cpp.
> 
> https://cr.openjdk.java.net/~stefank/8230562/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8230562
> 
> Oracle doesn't need this file anymore. Is anyone else replacing this with their own version, or can we simply remove it?
> 
Thanks for cleaning this up, looks good,
StefanJ

> Thanks,
> StefanK


From stefan.karlsson at oracle.com  Mon Sep  9 08:42:01 2019
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Mon, 9 Sep 2019 10:42:01 +0200
Subject: RFR: 8230562: Remove g1HeapSizingPolicy_ext.cpp
In-Reply-To: <E40ADCEE-96C8-4179-A331-F336CBC9F2A2@oracle.com>
References: <8bdd1745-717d-a134-726b-8e320f0f4d69@oracle.com>
 <E40ADCEE-96C8-4179-A331-F336CBC9F2A2@oracle.com>
Message-ID: <5760ef3f-c0a2-12ab-e458-11098ed09a3a@oracle.com>

Thanks, StefanJ.

StefanK

On 2019-09-09 10:38, Stefan Johansson wrote:
> Hi Stefan,
> 
>> 4 sep. 2019 kl. 13:23 skrev Stefan Karlsson <stefan.karlsson at oracle.com>:
>>
>> Hi all,
>>
>> Please review this patch to remove g1HeapSizingPolicy_ext.cpp.
>>
>> https://cr.openjdk.java.net/~stefank/8230562/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8230562
>>
>> Oracle doesn't need this file anymore. Is anyone else replacing this with their own version, or can we simply remove it?
>>
> Thanks for cleaning this up, looks good,
> StefanJ
> 
>> Thanks,
>> StefanK
> 

From glaubitz at physik.fu-berlin.de  Mon Sep  9 10:46:45 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Sep 2019 12:46:45 +0200
Subject: 8230708: Linux-sparc fails to build with gcc-9
In-Reply-To: <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>
References: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
 <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>
Message-ID: <46fb6b2c-04e6-77c9-1ca3-8dc64ae0628e@physik.fu-berlin.de>

Hi!

Thanks, Paul!

Can I get a second review? The tests in the submit repo also passed without
any problems, so I would be ready to push.

I have cloned a fresh copy of the jdk repository to make sure I'm pushing
from a clean repo.

Adrian

On 9/6/19 8:20 PM, Hohensee, Paul wrote:
> Looks good.
> 
> Paul
> 
> ?On 9/6/19, 6:35 AM, "hotspot-dev on behalf of John Paul Adrian Glaubitz" <hotspot-dev-bounces at openjdk.java.net on behalf of glaubitz at physik.fu-berlin.de> wrote:
> 
>      Hello!
>      
>      Please review this small change [1] which fixes the build on Linux-sparc
>      with gcc-9 as the default C/C++ compiler [2].
>      
>      Cheers,
>      Adrian
>      
>      > [1] http://cr.openjdk.java.net/~glaubitz/8230708/webrev.01/
>      > [2] https://bugs.openjdk.java.net/browse/JDK-8230708
>      
>      --
>        .''`.  John Paul Adrian Glaubitz
>      : :' :  Debian Developer - glaubitz at debian.org
>      `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>         `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>      
>      
> 

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Mon Sep  9 12:37:40 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Sep 2019 22:37:40 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>
Message-ID: <2eef26da-1510-bb48-f776-7bbf90c94da4@oracle.com>

Hi Robbin,

Thanks for taking a look.

On 9/09/2019 6:38 pm, Robbin Ehn wrote:
> Hi David,
> 
> 3598 void os::interrupt(Thread* thread) {
> 3599?? debug_only(Thread::check_for_dangling_thread_pointer(thread);)
> 3600?? assert(thread->is_Java_thread(), "invariant");
> 3601?? JavaThread* jt = (JavaThread*) thread;
> 
> Why not change the argument type to JavaThread* ?

To be honest this was the last part I had to fix because of the movement 
of the _SleepEvent and initially I just did a cast then thought that was 
too clunky so used the same approach as had earlier been in the sleep 
code. Changing the parameter would have been simpler as it turns out. 
But this code will only last a few days anyway :)

Thanks,
David

> Thanks, Robbin
> 
> On 9/9/19 7:21 AM, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>
>> This is the next step in the sleep/interrupt support code reshuffle. 
>> Now that os::sleep is platform independent and only applicable to 
>> JavaThreads, we can move it to JavaThread as an instance method.
>>
>> Summary of changes:
>> - os::sleep moved to JavaThread::sleep as instance method
>> - signature changed to return bool - true means timed-out; false means 
>> interrupted
>> - rearranged the sleep code slightly to remove the initial 
>> back-to-back nanoTime() calls - as suggested by Roger.
>> - _SleepEvent moved from Thread to JavaThread
>> - minor changes to os::interrupt to account for move to JavaThread 
>> (this code will also be moved to JavaThread in the next fix)
>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>
>> Testing:
>> ??- tiers 1-3
>>
>> Thanks,
>> David

From david.holmes at oracle.com  Mon Sep  9 12:42:28 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Sep 2019 22:42:28 +1000
Subject: 8230708: Linux-sparc fails to build with gcc-9
In-Reply-To: <46fb6b2c-04e6-77c9-1ca3-8dc64ae0628e@physik.fu-berlin.de>
References: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
 <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>
 <46fb6b2c-04e6-77c9-1ca3-8dc64ae0628e@physik.fu-berlin.de>
Message-ID: <a58c2a71-6de3-9340-be67-c4c279f157c5@oracle.com>

Hi Adrian,

On 9/09/2019 8:46 pm, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> Thanks, Paul!
> 
> Can I get a second review? The tests in the submit repo also passed without
> any problems, so I would be ready to push.

Looks okay. Did the submit repo test Solaris sparc?

Thanks,
David

> I have cloned a fresh copy of the jdk repository to make sure I'm pushing
> from a clean repo.
> 
> Adrian
> 
> On 9/6/19 8:20 PM, Hohensee, Paul wrote:
>> Looks good.
>>
>> Paul
>>
>> ?On 9/6/19, 6:35 AM, "hotspot-dev on behalf of John Paul Adrian 
>> Glaubitz" <hotspot-dev-bounces at openjdk.java.net on behalf of 
>> glaubitz at physik.fu-berlin.de> wrote:
>>
>> ???? Hello!
>> ???? Please review this small change [1] which fixes the build on 
>> Linux-sparc
>> ???? with gcc-9 as the default C/C++ compiler [2].
>> ???? Cheers,
>> ???? Adrian
>> ???? > [1] http://cr.openjdk.java.net/~glaubitz/8230708/webrev.01/
>> ???? > [2] https://bugs.openjdk.java.net/browse/JDK-8230708
>> ???? --
>> ?????? .''`.? John Paul Adrian Glaubitz
>> ???? : :' :? Debian Developer - glaubitz at debian.org
>> ???? `. `'?? Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>> ??????? `-??? GPG: 62FF 8A75 84E0 2956 9546? 0006 7426 3B37 F5B5 F913
>>
> 

From robbin.ehn at oracle.com  Mon Sep  9 12:45:12 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 9 Sep 2019 14:45:12 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <f52eaf30-f804-eb0a-7cc9-faf3dadddb0c@oracle.com>
 <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com>
 <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
Message-ID: <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>

Hi all,

Me and Erik had some offline discussions, which ended up in this incremental change:
http://cr.openjdk.java.net/~rehn/8226705/v2/inc/webrev/

Full:
http://cr.openjdk.java.net/~rehn/8226705/v2/full/webrev/

The problem is a nmethods state must never go backwards.
When the methods code is set to the compiled code it can be made not_entrant.
(it can be set to not_entrant before not having Compiled_lock)
When unlinking the methods code must point to the nmethod.

If we set code before changing state, it can go backwards.
If we set state before setting code, we can't unlink it.

This solution uses the new CompiledMethod_lock to synchronize code and state 
changes. (unloaded don't need the lock since it require a safepoint to happen)

But this resulted in a circular lock issue with OsrList_lock.
Therefore OsrList_lock is removed, instead we use CompiledMethod_lock.

After this patch it should be possible to remove Compile_lock from some paths. 
(Note that JVMCI is missing Compile_lock from several pathes, but fewer with 
this changeset)

Also InterpreterRuntime::frequency_counter_overflow_inner seem to have the same 
bug as the reason for this redo: BiasedLocking::revoke(objects_to_revoke, thread);
The objects could have been rebaised by the time we return from it.
I think we should call the new 
BiasedLocking::revoke_own_locks(objects_to_revoke->at(i), thread); here also.

Passes t1-5 twice and KS 60 min.

@Erik I stayed with current is_in_use (not_installed + in_use), there were to 
many places and many of them needed an equivalent method if is_in_use was to be 
changed (to only in_use). I didn't see any issue with using the current definition.

Thanks, Robbin

On 8/29/19 4:35 PM, Erik ?sterlund wrote:
> Hi Robbin,
> 
> On 2019-08-29 14:25, Robbin Ehn wrote:
>> Hi Erik, thanks for having a look.
>>
>> Just some short answers and questions.
>>
>> On 8/29/19 12:01 PM, Erik ?sterlund wrote:
>>> Hi Robbin,
>>>
>>> Glad to see this work making it back again. Last time this patch was 
>>> proposed, there were no guards against non-monotonic nmethod state 
>>> transitions. Today there are (since 
>>> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, if you 
>>> call make_not_entrant() on an nmethod that has racingly become zombie, it is 
>>> today impossible to resurrect that nmethod. Instead, make_not_entrant() will 
>>> return false.
>>
>> Great, I'll have a look.
>>
>>>
>>> In particular, I think that is what the following code in the patch is 
>>> guarding against (in codeCache.cpp):
>>>
>>> 1150 // Mark methods for deopt (if safe or possible).
>>> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() {
>>> 1152?? MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>>> 1153?? CompiledMethodIterator 
>>> iter(CompiledMethodIterator::only_alive_and_not_unloading);
>>> 1154?? while(iter.next()) {
>>> 1155???? CompiledMethod* nm = iter.method();
>>> 1156???? if (!nm->method()->is_method_handle_intrinsic() &&
>>> 1157???????? !nm->is_not_installed() &&
>>> 1158???????? nm->is_in_use() &&
>>> 1159???????? !nm->is_native_method()) {
>>> 1160?????? // Intrinsics and native methods are never deopted. A method that is
>>> 1161?????? // not installed yet or is not in use is not safe to deopt; the
>>> 1162?????? // is_in_use() check covers the not_entrant and not zombie cases.
>>> 1163?????? // Note: A not_entrant method can become a zombie at anytime if it 
>>> was
>>> 1164?????? // made not_entrant before the previous safepoint/handshake.
>>> 1165?????? nm->mark_for_deoptimization();
>>> 1166???? }
>>> 1167?? }
>>> 1168 }
>>>
>>> In fact, this code is also guarding against is_not_installed nmethods (which 
>>> was introduced as a new function). If we find that an nmethod is bad and say 
>>> it needs deoptimization, and that nmethod is just about to get installed, it 
>>> seems to me that skipping that nmethod and not making it not entrant is 
>>> really dangerous and will eventually lead to a crash. Because in ciEnv.cpp we 
>>> set_code to the about to be installed nmethod, and it will get called without 
>>> anything stopping the invalid code from being executed by mutators, and it 
>>> was being invalidated for a reason. So basically we really do have to make 
>>> these not entrant, or we will blow up.
>>>
>>> I guess the reason you needed this check is because make_in_use() doesn't 
>>> check what the current state is, causing monotonicity problems, making a 
>>> potentially already not entrant nmethod become in_use, eventually blowing up 
>>> asserts and probably the VM. Regrettably, make_in_use() still does that, 
>>> because I had no need for changing it to use nmethod::try_transition in 
>>> 8224674, nobody previously could find these nmethods. In retrospect, not 
>>> changing that was a bit silly. So if we just change make_in_use() to use 
>>> nmethod::try_transition instead, then you can remove the !is_not_installed 
>>> check... which I argue we have to do. The reason we never ran in to this 
>>> before is because we made the nmethods not entrant in a safepoint, and 
>>> between making an nmethod and making it in_use, there is no safepoint check, 
>>> so they were never observed in this state.
>>>
>>
>> Yes, thread A is creating a new method X, it have state not installed.
>> If we make method X not entrant, Thread A will flip it back to in_use, which bad
>> and we crash. mark_all_nmethods_for_deoptimization is a test method used in the
>> new jtreg test, which is the only use (I see dtrace have some hack to use it, it
>> can crash the vm).
> 
> Exactly. However, what you are missing here is that this does not happen only 
> for the whitebox test, now that we do normal deopt with handshakes.
> 
> Consider the following race.
> 
> A compiler thread compiles a new nmethod. In this nmethod, it's assumed that a 
> certain invoke_virtual callsite is completely monomorphic, and the compiler 
> chooses to implement the callsite with a direct call, which is only valid given 
> its monomorphism. The compilation finishes, and at the very end of the process, 
> the code cache lock is grabbed, under which we allocate the new nmethod, verify 
> the assumptions made (which still hold), inject entries in DependencyContexts so 
> that if these assumptions change, we will deopt, and then unlock the code cache 
> lock. The nmethod is now still in the state not_installed.
> 
> What can happen now is that another thread loads a class that makes the callsite 
> potentially megamorphic. Deopt is triggered, walking the dependency contexts 
> under the CodeCache_lock, marking things that are now bad. In this list we will 
> find the newly compiled nmethod that has not been made in_use yet. It is marked 
> for deoptimization. Then the Deoptimization::deoptimize_all_marked() function is 
> called to make sure that we 1) make all the marked nmethods not_entrant, and 2) 
> arm the bad activation records in the stack. Now the first step of the two grabs 
> the code cache lock, and walks the code cache. It finds our about to be 
> installed nmethod, and shoots make_not_entrant() at it, racing with the compiler 
> thread calling make_in_use() on it.
> 
> This is why I advocate an approach where we simply make it safe to call 
> make_in_use() racing with make_not_entrant(), instead of trying to chase down 
> all possible scenarios in which this can happen. I can imagine a number of 
> others, now that deoptimization is being done with handshakes.
> 
>>> ... and similarly here:
>>>
>>> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) {
>>> 1193?????? // only_alive_and_not_unloading() can return not_entrant nmethods.
>>> 1194?????? // A not_entrant method can become a zombie at anytime if it was
>>> 1195?????? // made not_entrant before the previous safepoint/handshake. The
>>> 1196?????? // is_in_use() check covers the not_entrant and not zombie cases
>>> 1197?????? // that have become true after the method was marked for deopt.
>>> 1198?????? nm->make_not_entrant();
>>> 1199???? }
>>>
>>> ... we now don't need the guard against is_in_use() here.
>>
>> Here we don't need that, but we don't need !nm->is_not_entrant() either, since
>> it would return false as you say!?
> 
> Indeed. All state checks to see if it is even safe to call the state transition 
> function should be removed, as it should always be safe.
> 
>> If we should have an early filter it think nm->is_in_use() is clearer than:
>> not not entrant ;) (since the not_installed is normally not seen here)
> 
> The transitioning functions themselves already have early checks, so there 
> really is nothing to gain from checking if we should transition first and then 
> doing it.
> 
>>>
>>> For what I propose to work out, we need to change nmethod::make_in_use to use 
>>> nmethod::try_transition, and AOTCompiledMethod::make_entrant() needs to also 
>>> return false when encountering a not_entrant nmethod, enforcing monotonicity, 
>>> instead of asserting about that. AOT methods may turn not_in_use AOT methods 
>>> to in_use, but not not_entrant to in_use. Once not_entrant, an AOT methods 
>>> should remain not entrant forever.
>>
>> The only time we see methods which are not installed should be methods that will
>> never be deoptimize (except when calling the test method
>> mark_all_nmethods_for_deoptimization), intrinsic and native.
> 
> That's not right. It's visible to a bunch of deoptimizations.
> 
>> And if I remember correctly make_in_use is called in a constructor which
>> requires extra error-handling. Construction would fail if try_transition failed.
>> The assumption about these 'never deopted' methods seem to be just that :)
> 
> That is also not right. We grab the code cache lock, create the nmethod, verify 
> dependencies, install dependencies, drop the code cache lock, all under 
> not_installed. It's only after linking the Method to the code, that we 
> eventually set it to in_use. So it's visible for longer than you thought. And 
> it's visible to calls, a small instant before we change the state to in_use(). 
> That's what I claim isn't right. We don't want to be able to call into these guys.
> 
>>>
>>> So basically, these guards are for something that used to be racy and 
>>> dangerous due to the lack of guards inside of the state transitions, and 
>>> today that is completely harmless, as the proper guards are in the attempts 
>>> to change state. I would prefer to remove these guards, as it is confusing to 
>>> the reader that we are guarding against a problem that can't happen. So I 
>>> think you can remove the various checks for what state the nmethod is in, the 
>>> comments describing races, and just keep the checks if it's a method handle 
>>> intrinsic or native method.
>>
>> I'll revisit this. Was a few months since I did this.
> 
> Okay!
> 
>>>
>>> In deoptimize.cpp, the fetch_unroll_info_helper function has moved down, 
>>> making it difficult to review as shows the code delta as if everything 
>>> changed. So I can't see what actually changed there. :( Would you mind moving 
>>> that code back so the webrev shows what changed there?
>>
>> I have inserted two new static functions before fetch_unroll_info_helper,
>> since code from fetch_unroll_info_helper are in these functions diff do this.
>> They are static function they are best off before, and putting after them I
>> don't think would help the diff tool + I need fwd decl.
>> Suggestion?
> 
> Okay, I will try to work out what the actual diff is manually.
> 
> Thanks,
> /Erik
> 
>> Thanks, Robbin
>>
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 2019-08-28 11:57, Robbin Ehn wrote:
>>>> Hi, hotspot-dev was the intended list.
>>>>
>>>> Thanks, Robbin
>>>>
>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>> Hi all, please consider,
>>>>>
>>>>> To get away from the issues of us revoking in the handshake, but before deopt
>>>>> the locks get re-biased before we hit deopt handler, we instead revoke in 
>>>>> deopt
>>>>> handler.
>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>>>
>>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge 
>>>>> conflicts
>>>>> some pieces did not apply:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>>> So this is what was reviewed.
>>>>>
>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>
>>>>> Bug 8224795 fix is here:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>>
>>>>>
>>>>> After this we have the same functionally as the reverted change-set.
>>>>>
>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>>
>>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>>> Here is a refactoring of that code. (also removed a dead method in 
>>>>> biasedlocking):
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>
>>>>> And here is full:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>
>>>>> Also a full squashed patch file:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>
>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>>> running.
>>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>>

From glaubitz at physik.fu-berlin.de  Mon Sep  9 12:49:50 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Mon, 9 Sep 2019 14:49:50 +0200
Subject: 8230708: Linux-sparc fails to build with gcc-9
In-Reply-To: <a58c2a71-6de3-9340-be67-c4c279f157c5@oracle.com>
References: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
 <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>
 <46fb6b2c-04e6-77c9-1ca3-8dc64ae0628e@physik.fu-berlin.de>
 <a58c2a71-6de3-9340-be67-c4c279f157c5@oracle.com>
Message-ID: <2a078422-db69-69fc-526e-244db278ba09@physik.fu-berlin.de>

Hi David!

On 9/9/19 2:42 PM, David Holmes wrote:
> On 9/09/2019 8:46 pm, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> Thanks, Paul!
>>
>> Can I get a second review? The tests in the submit repo also passed without
>> any problems, so I would be ready to push.
> 
> Looks okay. Did the submit repo test Solaris sparc?

Not sure. The mail I got was:

Job: mach5-one-glaubitz-JDK-8230708-20190906-1427-4921818
BuildId: 2019-09-06-1422073.glaubitz.source
No failed tests
Tasks Summary

     PASSED: 77
     KILLED: 0
     EXECUTED_WITH_FAILURE: 0
     NOTHING_TO_RUN: 0
     HARNESS_ERROR: 0
     NA: 0
     FAILED: 0
     UNABLE_TO_RUN: 0

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Mon Sep  9 13:08:22 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Sep 2019 23:08:22 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <2eef26da-1510-bb48-f776-7bbf90c94da4@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>
 <2eef26da-1510-bb48-f776-7bbf90c94da4@oracle.com>
Message-ID: <ffdf9841-59b2-7715-6b2d-fb61ebdaf24a@oracle.com>

Sorry confused two different sets of changes ...

On 9/09/2019 10:37 pm, David Holmes wrote:
> Hi Robbin,
> 
> Thanks for taking a look.
> 
> On 9/09/2019 6:38 pm, Robbin Ehn wrote:
>> Hi David,
>>
>> 3598 void os::interrupt(Thread* thread) {
>> 3599?? debug_only(Thread::check_for_dangling_thread_pointer(thread);)
>> 3600?? assert(thread->is_Java_thread(), "invariant");
>> 3601?? JavaThread* jt = (JavaThread*) thread;
>>
>> Why not change the argument type to JavaThread* ?

The interrupt code is all being changed in an upcoming fix so I didn't 
worry too much about the mechanisms at this stage.

David
-----

> To be honest this was the last part I had to fix because of the movement 
> of the _SleepEvent and initially I just did a cast then thought that was 
> too clunky so used the same approach as had earlier been in the sleep 
> code. Changing the parameter would have been simpler as it turns out. 
> But this code will only last a few days anyway :)
> 
> Thanks,
> David
> 
>> Thanks, Robbin
>>
>> On 9/9/19 7:21 AM, David Holmes wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>
>>> This is the next step in the sleep/interrupt support code reshuffle. 
>>> Now that os::sleep is platform independent and only applicable to 
>>> JavaThreads, we can move it to JavaThread as an instance method.
>>>
>>> Summary of changes:
>>> - os::sleep moved to JavaThread::sleep as instance method
>>> - signature changed to return bool - true means timed-out; false 
>>> means interrupted
>>> - rearranged the sleep code slightly to remove the initial 
>>> back-to-back nanoTime() calls - as suggested by Roger.
>>> - _SleepEvent moved from Thread to JavaThread
>>> - minor changes to os::interrupt to account for move to JavaThread 
>>> (this code will also be moved to JavaThread in the next fix)
>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>
>>> Testing:
>>> ??- tiers 1-3
>>>
>>> Thanks,
>>> David

From david.holmes at oracle.com  Mon Sep  9 13:12:45 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Sep 2019 23:12:45 +1000
Subject: 8230708: Linux-sparc fails to build with gcc-9
In-Reply-To: <2a078422-db69-69fc-526e-244db278ba09@physik.fu-berlin.de>
References: <d491d123-612f-5d26-008a-05aaa10573da@physik.fu-berlin.de>
 <3FEAD0CF-07F6-43D8-BA4D-D44AD2BC43F7@amazon.com>
 <46fb6b2c-04e6-77c9-1ca3-8dc64ae0628e@physik.fu-berlin.de>
 <a58c2a71-6de3-9340-be67-c4c279f157c5@oracle.com>
 <2a078422-db69-69fc-526e-244db278ba09@physik.fu-berlin.de>
Message-ID: <9011ee2a-7184-6f3b-a89d-749864ca1f0f@oracle.com>

On 9/09/2019 10:49 pm, John Paul Adrian Glaubitz wrote:
> Hi David!
> 
> On 9/9/19 2:42 PM, David Holmes wrote:
>> On 9/09/2019 8:46 pm, John Paul Adrian Glaubitz wrote:
>>> Hi!
>>>
>>> Thanks, Paul!
>>>
>>> Can I get a second review? The tests in the submit repo also passed 
>>> without
>>> any problems, so I would be ready to push.
>>
>> Looks okay. Did the submit repo test Solaris sparc?
> 
> Not sure. The mail I got was:
> 
> Job: mach5-one-glaubitz-JDK-8230708-20190906-1427-4921818
> BuildId: 2019-09-06-1422073.glaubitz.source
> No failed tests
> Tasks Summary
> 
>  ??? PASSED: 77
>  ??? KILLED: 0
>  ??? EXECUTED_WITH_FAILURE: 0
>  ??? NOTHING_TO_RUN: 0
>  ??? HARNESS_ERROR: 0
>  ??? NA: 0
>  ??? FAILED: 0
>  ??? UNABLE_TO_RUN: 0

I checked it and it did build on Solaris sparc. So all good.

Thanks,
David

> Adrian
> 

From christian.hagedorn at oracle.com  Mon Sep  9 14:14:18 2019
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Mon, 9 Sep 2019 16:14:18 +0200
Subject: [14] RFR(XS): 8230762: Change MacroAssembler::debug32/64 to use fatal
 instead of assert
Message-ID: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>

Hi

Please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8230762
http://cr.openjdk.java.net/~chagedorn/8230762/webrev.00/

The webrev is based on JDK-8225653. MacroAssembler::debug32/64 is 
changed such that the last operation is fatal(). I think that some 
additional instructions like ThreadStateTransition::transition or 
tty->print_cr are then not needed anymore. I also ensured that after 
each debug32/64 call a hlt is directly emitted (which was required in 
generate_verify_oop - in MacroAssembler::stop we already have a hlt 
instruction afterwards).

Thank you!

Best regards,
Christian

From alexandr.miloslavskiy at gmail.com  Mon Sep  9 16:04:50 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Mon, 9 Sep 2019 18:04:50 +0200
Subject: How to native debug Java on macOS?
Message-ID: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>

Hello,

For a while now, I've been working on solving native JVM crashes in a 
third party library with lots on JNI. Some turn out to be library bugs, 
some are JVM bugs, some are OS bugs. Anyways, that involves a lot of 
work with a native debugger, such as WinDBG / GDB / LLDB.

Native-debugging JVM is harder then usual, because JVM raises lots of 
exceptions for internal purposes, and I have to skip them in my 
debugger. Eventually, I devised scripts for WinDBG (Windows) and GDB 
(Linux) to auto-skip those exceptions.

However, on macOS, it seems that LLDB debugger is unable to pass 
EXC_BAD_ACCESS down to application and instead get stuck on it. I spent 
a while and managed to get GDB running on macOS, but ran into other 
difficulties where GDB is unable to load debugging information for 
system libraries. I also think that in general, GDB is not very 
feature-reach in terms of macOS specific stuff.

I also tried to disable those internal exceptions in JVM, but it seems 
that it can't be done any easily.

So... How do you guys native-debug on macOS?

From kirk.pepperdine at gmail.com  Mon Sep  9 16:08:10 2019
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Mon, 9 Sep 2019 09:08:10 -0700
Subject: How to native debug Java on macOS?
In-Reply-To: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
Message-ID: <4C461FF8-470C-406A-9F95-2D769232644F@gmail.com>

Hi Alexander,

This is a very interesting question.  It seems as if you have some great tricks for debugging on Windows and Linux. Care to share?

Kind regards,
Kirk Pepperdine


> On Sep 9, 2019, at 9:04 AM, Alexander Miloslavskiy <alexandr.miloslavskiy at gmail.com> wrote:
> 
> Hello,
> 
> For a while now, I've been working on solving native JVM crashes in a third party library with lots on JNI. Some turn out to be library bugs, some are JVM bugs, some are OS bugs. Anyways, that involves a lot of work with a native debugger, such as WinDBG / GDB / LLDB.
> 
> Native-debugging JVM is harder then usual, because JVM raises lots of exceptions for internal purposes, and I have to skip them in my debugger. Eventually, I devised scripts for WinDBG (Windows) and GDB (Linux) to auto-skip those exceptions.
> 
> However, on macOS, it seems that LLDB debugger is unable to pass EXC_BAD_ACCESS down to application and instead get stuck on it. I spent a while and managed to get GDB running on macOS, but ran into other difficulties where GDB is unable to load debugging information for system libraries. I also think that in general, GDB is not very feature-reach in terms of macOS specific stuff.
> 
> I also tried to disable those internal exceptions in JVM, but it seems that it can't be done any easily.
> 
> So... How do you guys native-debug on macOS?


From bob.vandette at oracle.com  Mon Sep  9 16:18:20 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 9 Sep 2019 12:18:20 -0400
Subject: How to native debug Java on macOS?
In-Reply-To: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
Message-ID: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>

Have you tried putting these two lines in your ~/.lldbinit file?

process handle -s false SIGSEGV
process handle -s false SIGBUS

Bob Vandette

> On Sep 9, 2019, at 12:04 PM, Alexander Miloslavskiy <alexandr.miloslavskiy at gmail.com> wrote:
> 
> Hello,
> 
> For a while now, I've been working on solving native JVM crashes in a third party library with lots on JNI. Some turn out to be library bugs, some are JVM bugs, some are OS bugs. Anyways, that involves a lot of work with a native debugger, such as WinDBG / GDB / LLDB.
> 
> Native-debugging JVM is harder then usual, because JVM raises lots of exceptions for internal purposes, and I have to skip them in my debugger. Eventually, I devised scripts for WinDBG (Windows) and GDB (Linux) to auto-skip those exceptions.
> 
> However, on macOS, it seems that LLDB debugger is unable to pass EXC_BAD_ACCESS down to application and instead get stuck on it. I spent a while and managed to get GDB running on macOS, but ran into other difficulties where GDB is unable to load debugging information for system libraries. I also think that in general, GDB is not very feature-reach in terms of macOS specific stuff.
> 
> I also tried to disable those internal exceptions in JVM, but it seems that it can't be done any easily.
> 
> So... How do you guys native-debug on macOS?


From alexandr.miloslavskiy at gmail.com  Mon Sep  9 16:18:50 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Mon, 9 Sep 2019 18:18:50 +0200
Subject: How to native debug Java on macOS?
In-Reply-To: <4C461FF8-470C-406A-9F95-2D769232644F@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <4C461FF8-470C-406A-9F95-2D769232644F@gmail.com>
Message-ID: <8b4ef3dc-86b5-9f23-1417-19776a969c84@gmail.com>

> It seems as if you have some great tricks for debugging on Windows and Linux.

Yes, I managed to convince debuggers to auto-skip internal exceptions 
and pause on anything unexpected.

On Linux, this is rather easy to setup (a small gdb script), but on 
Windows, it's quite more complicated (needs JDK with debugging 
information, debugger plugin and a script for it).

The GDB script is below. If you think that it's bad, then I don't know 
who written it; but if you find it useful, then it was me :)

---------------------------------------------

# Ignore java's internal SIGSEGV
catch signal SIGSEGV
commands
	# SIGSEGV
	if (11 == $_siginfo.si_signo)
		# Doing this results in very weird behavior, assigning to 
'$sigsegv_rwAddr' will replace value in 'si_addr' instead.
		# This crashes VM later, because 'si_addr' gets corrupted.
		# set $sigsegv_rwAddr = $_siginfo._sifields._sigfault.si_addr

		# Didn't find a way to 'return' from 'commands'
		set $sigsegv_Known = 0

		# Skip polling page exceptions used in safepoints
		if (!$sigsegv_Known)
			if ((os::_polling_page <= $_siginfo._sifields._sigfault.si_addr) && 
($_siginfo._sifields._sigfault.si_addr < os::_polling_page + 4096))
				printf "SIGSEGV(%p): os::is_poll_address()=true\n", 
$_siginfo._sifields._sigfault.si_addr
				set $sigsegv_Known = 1
			end
		end

		# Skip implicit NullPointer exceptions
		if (!$sigsegv_Known)
			set $sigsegv_Thread = 'ThreadLocalStorage::thread'()
			if ($sigsegv_Thread)
				if ($sigsegv_Thread->is_Java_thread())
					set $sigsegv_JThread = (JavaThread*)$sigsegv_Thread
					set $sigsegv_stub = 
'SharedRuntime::continuation_for_implicit_exception'($sigsegv_JThread, 
(address)$pc, SharedRuntime::IMPLICIT_NULL)
					if ($sigsegv_stub)
						printf "SIGSEGV(%p): 
SharedRuntime::continuation_for_implicit_exception()=%p\n", 
$_siginfo._sifields._sigfault.si_addr, (void*)$sigsegv_stub
						set $sigsegv_Known = 1
					end
				end
			end
		end

		# Skip cpuinfo
		if (!$sigsegv_Known)
			if ($pc == VM_Version::_cpuinfo_segv_addr)
				printf "SIGSEGV(%p): VM_Version::is_cpuinfo_segv_addr()=true\n", 
$_siginfo._sifields._sigfault.si_addr
				set $sigsegv_Known = 1
			end
		end

		if ($sigsegv_Known)
			continue
		end
	end
end

From alexandr.miloslavskiy at gmail.com  Mon Sep  9 16:57:25 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Mon, 9 Sep 2019 18:57:25 +0200
Subject: How to native debug Java on macOS?
In-Reply-To: <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
Message-ID: <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>

> Have you tried putting these two lines in your ~/.lldbinit file?
> process handle -s false SIGSEGV
> process handle -s false SIGBUS

Hmm, these seem to work...

Previously, on two different occasions, I spent a couple hours trying to 
get LLDB to work, also trying these very same commands, but failed. Back 
then I was stuck on EXC_BAD_ACCESS, from which I couldn't continue - it 
simply reoccurred again.

However, this time it works. If for example I run these:
	process handle --pass true --stop false SIGSEGV
	process handle --pass true --stop false SIGBUS

Then LLDB successfully skips all exceptions and my application runs as 
intended. Not sure why I was blocked previously.

Thanks!


From daniel.daugherty at oracle.com  Mon Sep  9 17:27:39 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 9 Sep 2019 13:27:39 -0400
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
Message-ID: <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>

On 9/9/19 1:21 AM, David Holmes wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/

src/hotspot/cpu/x86/rdtsc_x86.cpp
 ??? No comments.

src/hotspot/os/posix/os_posix.cpp
 ??? L648: ? assert(thread->is_Java_thread(), "invariant");
 ??? L649: ? JavaThread* jt = (JavaThread*) thread;
 ??????? I was expecting this change with your "interrupt" bug.
 ??????? Are we ready for this assert() now?

src/hotspot/os/windows/os_windows.cpp
 ??? L3600: ? assert(thread->is_Java_thread(), "invariant");
 ??? L3601: ? JavaThread* jt = (JavaThread*) thread;
 ??????? I was expecting this change with your "interrupt" bug.
 ??????? Are we ready for this assert() now?

src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
 ??? No comments.

src/hotspot/share/jvmci/jvmciCompiler.cpp
 ??? No comments.

src/hotspot/share/jvmci/jvmciRuntime.cpp
 ??? No comments.

src/hotspot/share/prims/jvm.cpp
 ??? No comments.

src/hotspot/share/runtime/os.cpp
 ??? No comments.

src/hotspot/share/runtime/os.hpp
 ??? No comments.

src/hotspot/share/runtime/thread.cpp
 ??? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
 ??? L1815: ? _SleepEvent? = NULL;
 ??????? nit - please delete extra blank before '='.

 ??? L3403 - nit - please delete extra blank line.

src/hotspot/share/runtime/thread.hpp
 ??? No comments.

test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
 ??? No comments.

test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
 ??? No comments.

test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
 ??? No comments.


Thumbs up! I don't need to see a new webrev if you decide to
fix the nits.

Dan


>
> This is the next step in the sleep/interrupt support code reshuffle. 
> Now that os::sleep is platform independent and only applicable to 
> JavaThreads, we can move it to JavaThread as an instance method.
>
> Summary of changes:
> - os::sleep moved to JavaThread::sleep as instance method
> - signature changed to return bool - true means timed-out; false means 
> interrupted
> - rearranged the sleep code slightly to remove the initial 
> back-to-back nanoTime() calls - as suggested by Roger.
> - _SleepEvent moved from Thread to JavaThread
> - minor changes to os::interrupt to account for move to JavaThread 
> (this code will also be moved to JavaThread in the next fix)
> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>
> Testing:
> ?- tiers 1-3
>
> Thanks,
> David


From kim.barrett at oracle.com  Mon Sep  9 21:05:06 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Sep 2019 17:05:06 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
 <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
 <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>
Message-ID: <90A3DC17-A17F-46C8-9350-3CAF9B7DC5C0@oracle.com>

> On Sep 9, 2019, at 4:35 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
> 
> 
> 
> On 06/09/2019 15:15, coleen.phillimore at oracle.com wrote:
>> Can you send a webrev of the final version of this change?
>> thanks,
>> Coleen
> 
> I am unsure if this is the final version; I have not got an answer on my two suggestions. This is the one I prefer:
> 
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8227168/01_02/

This looks okay to me.

> 
> Full:
> http://cr.openjdk.java.net/~lkorinth/8227168/02/
> 
> Testing:
> Only comments added, no new testing.
> 
> Thanks,
> Leo



From david.holmes at oracle.com  Mon Sep  9 21:41:38 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 07:41:38 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
Message-ID: <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>

Hi Dan,

Thanks for taking a look.

On 10/09/2019 3:27 am, Daniel D. Daugherty wrote:
> On 9/9/19 1:21 AM, David Holmes wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
> 
> src/hotspot/cpu/x86/rdtsc_x86.cpp
>  ??? No comments.
> 
> src/hotspot/os/posix/os_posix.cpp
>  ??? L648: ? assert(thread->is_Java_thread(), "invariant");
>  ??? L649: ? JavaThread* jt = (JavaThread*) thread;
>  ??????? I was expecting this change with your "interrupt" bug.
>  ??????? Are we ready for this assert() now?
> 
> src/hotspot/os/windows/os_windows.cpp
>  ??? L3600: ? assert(thread->is_Java_thread(), "invariant");
>  ??? L3601: ? JavaThread* jt = (JavaThread*) thread;
>  ??????? I was expecting this change with your "interrupt" bug.
>  ??????? Are we ready for this assert() now?

It is already true that only JavaThreads use the interrupt facility. The 
forthcoming changes to the interrupt just make that more obvious:

os::interrupt is-called-from
   Thread::interrupt is called from
     JVM_Interrupt  // java.lang.Thread interrupt
     JvmtiEnv::InterruptThread // JVM TI InterruptThread
     JavaThread::send_thread_stop

so always applied to a JavaThread.

> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
>  ??? No comments.
> 
> src/hotspot/share/jvmci/jvmciCompiler.cpp
>  ??? No comments.
> 
> src/hotspot/share/jvmci/jvmciRuntime.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvm.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/os.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/os.hpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.cpp
>  ??? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
>  ??? L1815: ? _SleepEvent? = NULL;
>  ??????? nit - please delete extra blank before '='.
> 
>  ??? L3403 - nit - please delete extra blank line.

Nits will be fixed.

Thanks,
David
-----

> src/hotspot/share/runtime/thread.hpp
>  ??? No comments.
> 
> test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
>  ??? No comments.
> 
> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
>  ??? No comments.
> 
> test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
>  ??? No comments.
> 
> 
> Thumbs up! I don't need to see a new webrev if you decide to
> fix the nits.
> 
> Dan
> 
> 
>>
>> This is the next step in the sleep/interrupt support code reshuffle. 
>> Now that os::sleep is platform independent and only applicable to 
>> JavaThreads, we can move it to JavaThread as an instance method.
>>
>> Summary of changes:
>> - os::sleep moved to JavaThread::sleep as instance method
>> - signature changed to return bool - true means timed-out; false means 
>> interrupted
>> - rearranged the sleep code slightly to remove the initial 
>> back-to-back nanoTime() calls - as suggested by Roger.
>> - _SleepEvent moved from Thread to JavaThread
>> - minor changes to os::interrupt to account for move to JavaThread 
>> (this code will also be moved to JavaThread in the next fix)
>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>
>> Testing:
>> ?- tiers 1-3
>>
>> Thanks,
>> David
> 

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep  9 22:24:41 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 10 Sep 2019 00:24:41 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
Message-ID: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>

Consider these classes:

class A {
  class InnerA {}
}
class B extends A {
  class InnerB extends InnerA {}
}

When I run some introspection on B.InnerB, I find HotSpot producing this
object layout:

Size of object B$InnerB: 24 bytes
  Field A$InnerA . this$1 is at offset 12
  Field B$InnerB . this$1 is at offset 16

So the object has *two* outer references, one of type A and one of type B.

That is all fair and good, but: These two references *will always point to
the same object*. This follows from the syntactic rules on the Java level.
(<< Crucial part of the argument, so - is this correct?)

So, the question is: Wouldn't it save some RAM to just have one "this$1"
field?

The only downside would be that accesses to this$1 from code inside InnerB
would require a cast, as the remaining this$1 field would formally only
have type A.

I'm curious as to where there has ever been deliberation of this?

Best regards,
Stefan

-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep  9 22:31:14 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 10 Sep 2019 00:31:14 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
Message-ID: <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>

> I'm curious as to where there has ever been deliberation of this?

Uh.. "whether", of course.

On Tue, 10 Sep 2019 at 00:24, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Consider these classes:
>
> class A {
>   class InnerA {}
> }
> class B extends A {
>   class InnerB extends InnerA {}
> }
>
> When I run some introspection on B.InnerB, I find HotSpot producing this
> object layout:
>
> Size of object B$InnerB: 24 bytes
>   Field A$InnerA . this$1 is at offset 12
>   Field B$InnerB . this$1 is at offset 16
>
> So the object has *two* outer references, one of type A and one of type B.
>
> That is all fair and good, but: These two references *will always point
> to the same object*. This follows from the syntactic rules on the Java
> level. (<< Crucial part of the argument, so - is this correct?)
>
> So, the question is: Wouldn't it save some RAM to just have one "this$1"
> field?
>
> The only downside would be that accesses to this$1 from code inside InnerB
> would require a cast, as the remaining this$1 field would formally only
> have type A.
>
> I'm curious as to where there has ever been deliberation of this?
>
> Best regards,
> Stefan
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Mon Sep  9 22:39:33 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 08:39:33 +1000
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
Message-ID: <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>

Hi Stefan,

On 10/09/2019 8:31 am, Stefan Reich wrote:
>> I'm curious as to where there has ever been deliberation of this?
> 
> Uh.. "whether", of course.

Glad you made that correction :) I would hazard a guess that it has 
never been deliberated. AFAIK the representation of fields in the JVM is 
a mechanical translation of what is in the classfile, with no attempt to 
be clever about aliasing. Even though they point to the same instance 
the different typed fields may still be needed to ensure correct method 
resolution for non-virtual invocations.

Cheers,
David

> On Tue, 10 Sep 2019 at 00:24, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
> 
>> Consider these classes:
>>
>> class A {
>>    class InnerA {}
>> }
>> class B extends A {
>>    class InnerB extends InnerA {}
>> }
>>
>> When I run some introspection on B.InnerB, I find HotSpot producing this
>> object layout:
>>
>> Size of object B$InnerB: 24 bytes
>>    Field A$InnerA . this$1 is at offset 12
>>    Field B$InnerB . this$1 is at offset 16
>>
>> So the object has *two* outer references, one of type A and one of type B.
>>
>> That is all fair and good, but: These two references *will always point
>> to the same object*. This follows from the syntactic rules on the Java
>> level. (<< Crucial part of the argument, so - is this correct?)
>>
>> So, the question is: Wouldn't it save some RAM to just have one "this$1"
>> field?
>>
>> The only downside would be that accesses to this$1 from code inside InnerB
>> would require a cast, as the remaining this$1 field would formally only
>> have type A.
>>
>> I'm curious as to where there has ever been deliberation of this?
>>
>> Best regards,
>> Stefan
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
> 
> 

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep  9 22:46:50 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 10 Sep 2019 00:46:50 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
Message-ID: <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>

Hi David,

thanks for your answer.

> Even though they point to the same instance
the different typed fields may still be needed to ensure correct method
resolution for non-virtual invocations.

I think this is not a counterargument. We just change an access to a field
this$1 of type B into
an access to a field this$1 with type A followed by a cast to B. The result
will be the same in both cases, including the real and formal type. Method
invocation is not affected.

Many greetings :)


On Tue, 10 Sep 2019 at 00:39, David Holmes <david.holmes at oracle.com> wrote:

> Hi Stefan,
>
> On 10/09/2019 8:31 am, Stefan Reich wrote:
> >> I'm curious as to where there has ever been deliberation of this?
> >
> > Uh.. "whether", of course.
>
> Glad you made that correction :) I would hazard a guess that it has
> never been deliberated. AFAIK the representation of fields in the JVM is
> a mechanical translation of what is in the classfile, with no attempt to
> be clever about aliasing. Even though they point to the same instance
> the different typed fields may still be needed to ensure correct method
> resolution for non-virtual invocations.
>
> Cheers,
> David
>
> > On Tue, 10 Sep 2019 at 00:24, Stefan Reich <
> > stefan.reich.maker.of.eye at googlemail.com> wrote:
> >
> >> Consider these classes:
> >>
> >> class A {
> >>    class InnerA {}
> >> }
> >> class B extends A {
> >>    class InnerB extends InnerA {}
> >> }
> >>
> >> When I run some introspection on B.InnerB, I find HotSpot producing this
> >> object layout:
> >>
> >> Size of object B$InnerB: 24 bytes
> >>    Field A$InnerA . this$1 is at offset 12
> >>    Field B$InnerB . this$1 is at offset 16
> >>
> >> So the object has *two* outer references, one of type A and one of type
> B.
> >>
> >> That is all fair and good, but: These two references *will always point
> >> to the same object*. This follows from the syntactic rules on the Java
> >> level. (<< Crucial part of the argument, so - is this correct?)
> >>
> >> So, the question is: Wouldn't it save some RAM to just have one "this$1"
> >> field?
> >>
> >> The only downside would be that accesses to this$1 from code inside
> InnerB
> >> would require a cast, as the remaining this$1 field would formally only
> >> have type A.
> >>
> >> I'm curious as to where there has ever been deliberation of this?
> >>
> >> Best regards,
> >> Stefan
> >>
> >> --
> >> Stefan Reich
> >> BotCompany.de // Java-based operating systems
> >>
> >
> >
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Mon Sep  9 22:50:36 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 08:50:36 +1000
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <90A3DC17-A17F-46C8-9350-3CAF9B7DC5C0@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
 <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
 <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>
 <90A3DC17-A17F-46C8-9350-3CAF9B7DC5C0@oracle.com>
Message-ID: <c034759c-703f-f583-8210-65889fa252ea@oracle.com>

+1

Thanks,
David

On 10/09/2019 7:05 am, Kim Barrett wrote:
>> On Sep 9, 2019, at 4:35 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>
>>
>>
>> On 06/09/2019 15:15, coleen.phillimore at oracle.com wrote:
>>> Can you send a webrev of the final version of this change?
>>> thanks,
>>> Coleen
>>
>> I am unsure if this is the final version; I have not got an answer on my two suggestions. This is the one I prefer:
>>
>> Incremental:
>> http://cr.openjdk.java.net/~lkorinth/8227168/01_02/
> 
> This looks okay to me.
> 
>>
>> Full:
>> http://cr.openjdk.java.net/~lkorinth/8227168/02/
>>
>> Testing:
>> Only comments added, no new testing.
>>
>> Thanks,
>> Leo
> 
> 

From david.holmes at oracle.com  Mon Sep  9 22:55:18 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 08:55:18 +1000
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
Message-ID: <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>

On 10/09/2019 8:46 am, Stefan Reich wrote:
> Hi David,
> 
> thanks for your answer.
> 
>  > Even though they point to the same instance
> the different typed fields may still be needed to ensure correct method
> resolution for non-virtual invocations.
> 
> I think?this is not a counterargument. We just change an access to a 
> field this$1 of type B into
> an access to a field this$1 with type A followed by a cast to B. The 
> result will be the same in both cases, including the real and formal 
> type. Method invocation is not affected.

But you're not talking about bytecode here you're talking about inside 
the VM. If there is an invokespecial on this$1 of type A then the 
constant pool lookup of its type will be A and we will resolve the call 
based on A's methods. If it were of type B then the resolution process 
would be different. There's nowhere to "insert a cast" here.

BTW what introspection tool did you use to show this?

Cheers,
David

> Many greetings :)
> 
> 
> On Tue, 10 Sep 2019 at 00:39, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Stefan,
> 
>     On 10/09/2019 8:31 am, Stefan Reich wrote:
>      >> I'm curious as to where there has ever been deliberation of this?
>      >
>      > Uh.. "whether", of course.
> 
>     Glad you made that correction :) I would hazard a guess that it has
>     never been deliberated. AFAIK the representation of fields in the
>     JVM is
>     a mechanical translation of what is in the classfile, with no
>     attempt to
>     be clever about aliasing. Even though they point to the same instance
>     the different typed fields may still be needed to ensure correct method
>     resolution for non-virtual invocations.
> 
>     Cheers,
>     David
> 
>      > On Tue, 10 Sep 2019 at 00:24, Stefan Reich <
>      > stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
>      >
>      >> Consider these classes:
>      >>
>      >> class A {
>      >>? ? class InnerA {}
>      >> }
>      >> class B extends A {
>      >>? ? class InnerB extends InnerA {}
>      >> }
>      >>
>      >> When I run some introspection on B.InnerB, I find HotSpot
>     producing this
>      >> object layout:
>      >>
>      >> Size of object B$InnerB: 24 bytes
>      >>? ? Field A$InnerA . this$1 is at offset 12
>      >>? ? Field B$InnerB . this$1 is at offset 16
>      >>
>      >> So the object has *two* outer references, one of type A and one
>     of type B.
>      >>
>      >> That is all fair and good, but: These two references *will
>     always point
>      >> to the same object*. This follows from the syntactic rules on
>     the Java
>      >> level. (<< Crucial part of the argument, so - is this correct?)
>      >>
>      >> So, the question is: Wouldn't it save some RAM to just have one
>     "this$1"
>      >> field?
>      >>
>      >> The only downside would be that accesses to this$1 from code
>     inside InnerB
>      >> would require a cast, as the remaining this$1 field would
>     formally only
>      >> have type A.
>      >>
>      >> I'm curious as to where there has ever been deliberation of this?
>      >>
>      >> Best regards,
>      >> Stefan
>      >>
>      >> --
>      >> Stefan Reich
>      >> BotCompany.de // Java-based operating systems
>      >>
>      >
>      >
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep  9 23:09:45 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 10 Sep 2019 01:09:45 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
Message-ID: <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>

>
> But you're not talking about bytecode here you're talking about inside
> the VM. If there is an invokespecial on this$1 of type A then the
> constant pool lookup of its type will be A and we will resolve the call
> based on A's methods. If it were of type B then the resolution process
> would be different. There's nowhere to "insert a cast" here.
>

Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a
case for this.

invokespecial invokes private instance methods, superclass methods or
constructors. Superclass methods don't apply, neither do constructors. And
calls to private methods happen through bridges (just verified this for
myself again :):

      13: aload_0
      14: getfield      #1                  // Field this$0:Lbla;
      17: invokestatic  #4                  // Method
bla.access$000:(Lbla;)V

So what remains?


> BTW what introspection tool did you use to show this?
>

My own tools ("JavaX")... here's the example program:
http://code.botcompany.de/1025166

Many greetings :)

From david.holmes at oracle.com  Mon Sep  9 23:17:22 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 09:17:22 +1000
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
Message-ID: <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>

On 10/09/2019 9:09 am, Stefan Reich wrote:
>     But you're not talking about bytecode here you're talking about inside
>     the VM. If there is an invokespecial on this$1 of type A then the
>     constant pool lookup of its type will be A and we will resolve the call
>     based on A's methods. If it were of type B then the resolution process
>     would be different. There's nowhere to "insert a cast" here.
> 
> 
> Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a 
> case for this.
> 
> invokespecial invokes private instance methods, superclass methods or 
> constructors. Superclass methods don't apply, neither do constructors. 
> And calls to private methods happen through bridges (just verified this 
> for myself again :):
> 
>  ? ? ? 13: aload_0
>  ? ? ? 14: getfield ? ? ?#1 ? ? ? ? ? ? ? ? ?// Field this$0:Lbla;
>  ? ? ? 17: invokestatic ?#4 ? ? ? ? ? ? ? ? ?// Method 
> bla.access$000:(Lbla;)V
> 
> So what remains?

This changed in JDK 11 with the addition of nestmates. Now inner classes 
have direct private access, no bridges needed, and we use invokespecial 
or invokevirtual as appropriate. For private methods invokevirtual is 
mainly used now, but of course we don't do virtual dispatch - there are 
special rules for private method resolution and selection.

class A {
   void m() {}
   class InnerA {
     void callM() { m(); }
   }
}

  void callM();
     descriptor: ()V
     flags: (0x0000)
     Code:
       stack=1, locals=1, args_size=1
          0: aload_0
          1: getfield      #1                  // Field this$0:LA;
          4: invokevirtual #13                 // Method A.m:()V
          7: return
       LineNumberTable:
         line 4: 0

>     BTW what introspection tool did you use to show this?
> 
> My own tools ("JavaX")... here's the example program: 
> http://code.botcompany.de/1025166

Thanks for the pointer.

Cheers,
David

> Many greetings :)

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep  9 23:30:06 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 10 Sep 2019 01:30:06 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
Message-ID: <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>

Oh, I didn't know about those JDK 11 changes. That may in fact break the
idea of merging the references. I'm sure it can still be done, but might
require a spec change. And who's gonna pay for that?

:-D

Thanks

On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com> wrote:

> On 10/09/2019 9:09 am, Stefan Reich wrote:
> >     But you're not talking about bytecode here you're talking about
> inside
> >     the VM. If there is an invokespecial on this$1 of type A then the
> >     constant pool lookup of its type will be A and we will resolve the
> call
> >     based on A's methods. If it were of type B then the resolution
> process
> >     would be different. There's nowhere to "insert a cast" here.
> >
> >
> > Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a
> > case for this.
> >
> > invokespecial invokes private instance methods, superclass methods or
> > constructors. Superclass methods don't apply, neither do constructors.
> > And calls to private methods happen through bridges (just verified this
> > for myself again :):
> >
> >        13: aload_0
> >        14: getfield      #1                  // Field this$0:Lbla;
> >        17: invokestatic  #4                  // Method
> > bla.access$000:(Lbla;)V
> >
> > So what remains?
>
> This changed in JDK 11 with the addition of nestmates. Now inner classes
> have direct private access, no bridges needed, and we use invokespecial
> or invokevirtual as appropriate. For private methods invokevirtual is
> mainly used now, but of course we don't do virtual dispatch - there are
> special rules for private method resolution and selection.
>
> class A {
>    void m() {}
>    class InnerA {
>      void callM() { m(); }
>    }
> }
>
>   void callM();
>      descriptor: ()V
>      flags: (0x0000)
>      Code:
>        stack=1, locals=1, args_size=1
>           0: aload_0
>           1: getfield      #1                  // Field this$0:LA;
>           4: invokevirtual #13                 // Method A.m:()V
>           7: return
>        LineNumberTable:
>          line 4: 0
>
> >     BTW what introspection tool did you use to show this?
> >
> > My own tools ("JavaX")... here's the example program:
> > http://code.botcompany.de/1025166
>
> Thanks for the pointer.
>
> Cheers,
> David
>
> > Many greetings :)
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From coleen.phillimore at oracle.com  Mon Sep  9 23:32:24 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 9 Sep 2019 19:32:24 -0400
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <c034759c-703f-f583-8210-65889fa252ea@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
 <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
 <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>
 <90A3DC17-A17F-46C8-9350-3CAF9B7DC5C0@oracle.com>
 <c034759c-703f-f583-8210-65889fa252ea@oracle.com>
Message-ID: <50543be5-29e6-c90e-c13f-c37afc4adac7@oracle.com>

+1

Except in

http://cr.openjdk.java.net/~lkorinth/8227168/02/src/hotspot/share/memory/allocation.hpp.udiff.html

Can you not document FREE_FAST?? It shouldn't be advertised.? If you 
delete this line, I don't need to see another webrev and I won't argue 
if you don't want to delete the line, but FREE_FAST is blek.

thanks,
Coleen

On 9/9/19 6:50 PM, David Holmes wrote:
> +1
>
> Thanks,
> David
>
> On 10/09/2019 7:05 am, Kim Barrett wrote:
>>> On Sep 9, 2019, at 4:35 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>
>>>
>>>
>>> On 06/09/2019 15:15, coleen.phillimore at oracle.com wrote:
>>>> Can you send a webrev of the final version of this change?
>>>> thanks,
>>>> Coleen
>>>
>>> I am unsure if this is the final version; I have not got an answer 
>>> on my two suggestions. This is the one I prefer:
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/01_02/
>>
>> This looks okay to me.
>>
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/02/
>>>
>>> Testing:
>>> Only comments added, no new testing.
>>>
>>> Thanks,
>>> Leo
>>
>>


From robbin.ehn at oracle.com  Tue Sep 10 08:37:20 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 10 Sep 2019 10:37:20 +0200
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <ffdf9841-59b2-7715-6b2d-fb61ebdaf24a@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>
 <2eef26da-1510-bb48-f776-7bbf90c94da4@oracle.com>
 <ffdf9841-59b2-7715-6b2d-fb61ebdaf24a@oracle.com>
Message-ID: <b907d671-f37e-2f20-eccc-304b0ee61d7c@oracle.com>

>>>
>>> Why not change the argument type to JavaThread* ?
> 
> The interrupt code is all being changed in an upcoming fix so I didn't worry too 
> much about the mechanisms at this stage.


Ok, looks fine, thanks!

/Robbin

> 
> David
> -----
> 
>> To be honest this was the last part I had to fix because of the movement of 
>> the _SleepEvent and initially I just did a cast then thought that was too 
>> clunky so used the same approach as had earlier been in the sleep code. 
>> Changing the parameter would have been simpler as it turns out. But this code 
>> will only last a few days anyway :)
>>
>> Thanks,
>> David
>>
>>> Thanks, Robbin
>>>
>>> On 9/9/19 7:21 AM, David Holmes wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>>
>>>> This is the next step in the sleep/interrupt support code reshuffle. Now 
>>>> that os::sleep is platform independent and only applicable to JavaThreads, 
>>>> we can move it to JavaThread as an instance method.
>>>>
>>>> Summary of changes:
>>>> - os::sleep moved to JavaThread::sleep as instance method
>>>> - signature changed to return bool - true means timed-out; false means 
>>>> interrupted
>>>> - rearranged the sleep code slightly to remove the initial back-to-back 
>>>> nanoTime() calls - as suggested by Roger.
>>>> - _SleepEvent moved from Thread to JavaThread
>>>> - minor changes to os::interrupt to account for move to JavaThread (this 
>>>> code will also be moved to JavaThread in the next fix)
>>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>>
>>>> Testing:
>>>> ??- tiers 1-3
>>>>
>>>> Thanks,
>>>> David

From vladimir.x.ivanov at oracle.com  Tue Sep 10 08:49:24 2019
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 10 Sep 2019 11:49:24 +0300
Subject: [14] RFR(XS): 8230762: Change MacroAssembler::debug32/64 to use
 fatal instead of assert
In-Reply-To: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
References: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
Message-ID: <11291ca4-72da-86df-87a9-f529de336c06@oracle.com>

x86 part looks good.

Best regards,
Vladimir Ivanov

On 09/09/2019 17:14, Christian Hagedorn wrote:
> Hi
> 
> Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8230762
> http://cr.openjdk.java.net/~chagedorn/8230762/webrev.00/
> 
> The webrev is based on JDK-8225653. MacroAssembler::debug32/64 is 
> changed such that the last operation is fatal(). I think that some 
> additional instructions like ThreadStateTransition::transition or 
> tty->print_cr are then not needed anymore. I also ensured that after 
> each debug32/64 call a hlt is directly emitted (which was required in 
> generate_verify_oop - in MacroAssembler::stop we already have a hlt 
> instruction afterwards).
> 
> Thank you!
> 
> Best regards,
> Christian

From david.holmes at oracle.com  Tue Sep 10 08:52:24 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Sep 2019 18:52:24 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <b907d671-f37e-2f20-eccc-304b0ee61d7c@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <f61c2fc0-afa1-734d-306c-e0916d7a193f@oracle.com>
 <2eef26da-1510-bb48-f776-7bbf90c94da4@oracle.com>
 <ffdf9841-59b2-7715-6b2d-fb61ebdaf24a@oracle.com>
 <b907d671-f37e-2f20-eccc-304b0ee61d7c@oracle.com>
Message-ID: <dc3a7829-2271-a331-3e92-d9cdbdd41bf9@oracle.com>

Thanks Robbin!

David

On 10/09/2019 6:37 pm, Robbin Ehn wrote:
>>>>
>>>> Why not change the argument type to JavaThread* ?
>>
>> The interrupt code is all being changed in an upcoming fix so I didn't 
>> worry too much about the mechanisms at this stage.
> 
> 
> Ok, looks fine, thanks!
> 
> /Robbin
> 
>>
>> David
>> -----
>>
>>> To be honest this was the last part I had to fix because of the 
>>> movement of the _SleepEvent and initially I just did a cast then 
>>> thought that was too clunky so used the same approach as had earlier 
>>> been in the sleep code. Changing the parameter would have been 
>>> simpler as it turns out. But this code will only last a few days 
>>> anyway :)
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks, Robbin
>>>>
>>>> On 9/9/19 7:21 AM, David Holmes wrote:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>>>
>>>>> This is the next step in the sleep/interrupt support code 
>>>>> reshuffle. Now that os::sleep is platform independent and only 
>>>>> applicable to JavaThreads, we can move it to JavaThread as an 
>>>>> instance method.
>>>>>
>>>>> Summary of changes:
>>>>> - os::sleep moved to JavaThread::sleep as instance method
>>>>> - signature changed to return bool - true means timed-out; false 
>>>>> means interrupted
>>>>> - rearranged the sleep code slightly to remove the initial 
>>>>> back-to-back nanoTime() calls - as suggested by Roger.
>>>>> - _SleepEvent moved from Thread to JavaThread
>>>>> - minor changes to os::interrupt to account for move to JavaThread 
>>>>> (this code will also be moved to JavaThread in the next fix)
>>>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>>>
>>>>> Testing:
>>>>> ??- tiers 1-3
>>>>>
>>>>> Thanks,
>>>>> David

From leo.korinth at oracle.com  Tue Sep 10 12:12:52 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 10 Sep 2019 14:12:52 +0200
Subject: RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
In-Reply-To: <50543be5-29e6-c90e-c13f-c37afc4adac7@oracle.com>
References: <93aa759d-657c-1f51-0b45-4ef788bae101@oracle.com>
 <40b5593c-c19e-9196-7447-c3d6881cef8e@oracle.com>
 <2B00AD5D-02C8-4DE9-8629-B74B11FA2D42@oracle.com>
 <9bd0d1c7-ef6a-9754-b0e4-23546cdcc37c@oracle.com>
 <e39b69e8-f04c-2cfc-efa6-e0871b3c8feb@oracle.com>
 <8238427F-08B5-4AE9-A2AE-63BE5276BF74@oracle.com>
 <40da7127-e8b8-4994-3e25-c37764f2d493@oracle.com>
 <ef0ab2f4-f140-6dee-cd2e-59d7cf8e81cc@oracle.com>
 <5ddec84c-58e0-5dba-177e-80454ef21cb2@oracle.com>
 <15d80214-2b2f-3d38-28e8-1f220f114c77@oracle.com>
 <86b271f0-3815-348f-985d-5fe2a794a098@oracle.com>
 <90A3DC17-A17F-46C8-9350-3CAF9B7DC5C0@oracle.com>
 <c034759c-703f-f583-8210-65889fa252ea@oracle.com>
 <50543be5-29e6-c90e-c13f-c37afc4adac7@oracle.com>
Message-ID: <00b55dd7-7bd7-eaf4-7a02-95496a4abaa3@oracle.com>



On 10/09/2019 01:32, coleen.phillimore at oracle.com wrote:
> +1
> 
> Except in
> 
> http://cr.openjdk.java.net/~lkorinth/8227168/02/src/hotspot/share/memory/allocation.hpp.udiff.html 
> 
> 
> Can you not document FREE_FAST?? It shouldn't be advertised.? If you 
> delete this line, I don't need to see another webrev and I won't argue 
> if you don't want to delete the line, but FREE_FAST is blek.
> 
> thanks,
> Coleen

Thanks all for helping me with feedback and reviewing my changes.

I will add Thomas, Kim, David and Coleen as reviewers and I will remove 
the comment describing FREE_FAST. I will not create a new webrev for that.

Thanks,
Leo


> 
> On 9/9/19 6:50 PM, David Holmes wrote:
>> +1
>>
>> Thanks,
>> David
>>
>> On 10/09/2019 7:05 am, Kim Barrett wrote:
>>>> On Sep 9, 2019, at 4:35 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>>
>>>>
>>>>
>>>> On 06/09/2019 15:15, coleen.phillimore at oracle.com wrote:
>>>>> Can you send a webrev of the final version of this change?
>>>>> thanks,
>>>>> Coleen
>>>>
>>>> I am unsure if this is the final version; I have not got an answer 
>>>> on my two suggestions. This is the one I prefer:
>>>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~lkorinth/8227168/01_02/
>>>
>>> This looks okay to me.
>>>
>>>>
>>>> Full:
>>>> http://cr.openjdk.java.net/~lkorinth/8227168/02/
>>>>
>>>> Testing:
>>>> Only comments added, no new testing.
>>>>
>>>> Thanks,
>>>> Leo
>>>
>>>
> 

From leo.korinth at oracle.com  Tue Sep 10 13:39:03 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Tue, 10 Sep 2019 15:39:03 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
Message-ID: <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>



On 02/09/2019 22:38, Kim Barrett wrote:
>> On Sep 2, 2019, at 9:06 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>
>> Hi!
>>
>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>
>> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp does (in addition to NULL the pointer) also set a counter to zero. Although my change "looks" correct, I tried follow the usage of deallocate_counters(), and could not find a call site. Should I create a bug on this, or am I missing something here?
> 
> Your modification to deallocate_counters looks fine.  I don't think
> you are missing anything, I think it's not called.  That does look
> like it might be a (pre-existing) bug.  Maybe they are immortal?  But
> that isn't obvious from a quick skim.
> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8230398
>>
>> Webrev:
>> http://cr.openjdk.java.net/~lkorinth/8230398
>>
>> Testing:
>> mach5 tier1-3
>>
>> Thanks,
>> Leo
> 
> ------------------------------------------------------------------------------
> 
> [pre-existing]
> There are some destructors that are unnecessarily nulling out members
> after deleting their values, such as here:
> 
> src/hotspot/share/classfile/classLoader.cpp
>   387   FREE_C_HEAP_ARRAY(const char, _name);
>   388   _name = NULL;
> 
> src/hotspot/share/gc/g1/sparsePRT.cpp
> 106 RSHashTable::~RSHashTable() {
> 
> src/hotspot/share/gc/shared/cardTableRS.cpp
> 626 CardTableRS::~CardTableRS() {
> 
> src/hotspot/share/runtime/thread.cpp
> 1330 NamedThread::~NamedThread() {
> 
> Your call whether you want to do anything about these with this change.
> 
> ------------------------------------------------------------------------------
> 
> Other than that, looks good.  I don't need another webrev if you
> decide to remove the above assignments to NULL near code you were
> already changing.  A more extensive pass for such should perhaps be a
> separate change.
> 
I will remove NULL assignments of fields in destructors and keep them 
otherwise.

I will also add a comment (// handles NULL pointers) to FreeHeap and 
os::free to not only describe behaviour, but also to establish a contract.

Also fixed indentation miss in os_perf_windows.cpp

Incremental:
http://cr.openjdk.java.net/~lkorinth/8230398/00_01

Full:
http://cr.openjdk.java.net/~lkorinth/8230398/01


running tests...

From chris.plummer at oracle.com  Tue Sep 10 19:52:06 2019
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 10 Sep 2019 12:52:06 -0700
Subject: How to native debug Java on macOS?
In-Reply-To: <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
 <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
Message-ID: <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>

On 9/9/19 9:57 AM, Alexander Miloslavskiy wrote:
>> Have you tried putting these two lines in your ~/.lldbinit file?
>> process handle -s false SIGSEGV
>> process handle -s false SIGBUS
>
> Hmm, these seem to work...
>
> Previously, on two different occasions, I spent a couple hours trying 
> to get LLDB to work, also trying these very same commands, but failed. 
> Back then I was stuck on EXC_BAD_ACCESS, from which I couldn't 
> continue - it simply reoccurred again.
>
> However, this time it works. If for example I run these:
> ????process handle --pass true --stop false SIGSEGV
> ????process handle --pass true --stop false SIGBUS
>
> Then LLDB successfully skips all exceptions and my application runs as 
> intended. Not sure why I was blocked previously.
>
> Thanks!
>
I went down this path last week and never did get it working, even with 
the above, so I'm not sure why it is suddenly working for you. I'm on 
xcode 10.2.1. Maybe 10.3 fixes this.

The lldb handling of EXC_BAD_ACCESS seems to be a known issue. lldb 
processes the EXC_BAD_ACCESS, not allowing it to eventually be consumed 
and converted to a SIGSEGV or SIGBUS (I assume the pthread library does 
this). Thus it never even gets to the part of lldb that cares that you 
did a "process handle" for SIGSEGV. Here's one case in point of a user 
running into this problem:

https://stackoverflow.com/questions/26829119/how-to-make-lldb-ignore-exc-bad-access-exception

And bugs filed:

https://bugs.llvm.org/show_bug.cgi?id=40669
https://bugs.llvm.org/show_bug.cgi?id=22868

The only solution I've found is to run with -Xint.

And two things to consider with the "process handle" commands. The first 
is it only impacts the current process. When you relaunch you need to 
execute them again. This brings us to the second issue which is putting 
"process handle" commands in your .lldbinit is pointless since you don't 
even have a process at that point.

cheers,

Chris


From chris.plummer at oracle.com  Tue Sep 10 20:00:49 2019
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 10 Sep 2019 13:00:49 -0700
Subject: How to native debug Java on macOS?
In-Reply-To: <8b4ef3dc-86b5-9f23-1417-19776a969c84@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <4C461FF8-470C-406A-9F95-2D769232644F@gmail.com>
 <8b4ef3dc-86b5-9f23-1417-19776a969c84@gmail.com>
Message-ID: <56772077-fc61-9f57-4ffa-19c27e0d7724@oracle.com>

On 9/9/19 9:18 AM, Alexander Miloslavskiy wrote:
>> It seems as if you have some great tricks for debugging on Windows 
>> and Linux.
>
> Yes, I managed to convince debuggers to auto-skip internal exceptions 
> and pause on anything unexpected.
>
> On Linux, this is rather easy to setup (a small gdb script), but on 
> Windows, it's quite more complicated (needs JDK with debugging 
> information, debugger plugin and a script for it).
>
> The GDB script is below. If you think that it's bad, then I don't know 
> who written it; but if you find it useful, then it was me :)
>
> ---------------------------------------------
>
> # Ignore java's internal SIGSEGV
> catch signal SIGSEGV
> commands
> ????# SIGSEGV
> ????if (11 == $_siginfo.si_signo)
> ??????? # Doing this results in very weird behavior, assigning to 
> '$sigsegv_rwAddr' will replace value in 'si_addr' instead.
> ??????? # This crashes VM later, because 'si_addr' gets corrupted.
> ??????? # set $sigsegv_rwAddr = $_siginfo._sifields._sigfault.si_addr
>
> ??????? # Didn't find a way to 'return' from 'commands'
> ??????? set $sigsegv_Known = 0
>
> ??????? # Skip polling page exceptions used in safepoints
> ??????? if (!$sigsegv_Known)
> ??????????? if ((os::_polling_page <= 
> $_siginfo._sifields._sigfault.si_addr) && 
> ($_siginfo._sifields._sigfault.si_addr < os::_polling_page + 4096))
> ??????????????? printf "SIGSEGV(%p): os::is_poll_address()=true\n", 
> $_siginfo._sifields._sigfault.si_addr
> ??????????????? set $sigsegv_Known = 1
> ??????????? end
> ??????? end
>
> ??????? # Skip implicit NullPointer exceptions
> ??????? if (!$sigsegv_Known)
> ??????????? set $sigsegv_Thread = 'ThreadLocalStorage::thread'()
> ??????????? if ($sigsegv_Thread)
> ??????????????? if ($sigsegv_Thread->is_Java_thread())
> ??????????????????? set $sigsegv_JThread = (JavaThread*)$sigsegv_Thread
> ??????????????????? set $sigsegv_stub = 
> 'SharedRuntime::continuation_for_implicit_exception'($sigsegv_JThread, 
> (address)$pc, SharedRuntime::IMPLICIT_NULL)
> ??????????????????? if ($sigsegv_stub)
> ??????????????????????? printf "SIGSEGV(%p): 
> SharedRuntime::continuation_for_implicit_exception()=%p\n", 
> $_siginfo._sifields._sigfault.si_addr, (void*)$sigsegv_stub
> ??????????????????????? set $sigsegv_Known = 1
> ??????????????????? end
> ??????????????? end
> ??????????? end
> ??????? end
>
> ??????? # Skip cpuinfo
> ??????? if (!$sigsegv_Known)
> ??????????? if ($pc == VM_Version::_cpuinfo_segv_addr)
> ??????????????? printf "SIGSEGV(%p): 
> VM_Version::is_cpuinfo_segv_addr()=true\n", 
> $_siginfo._sifields._sigfault.si_addr
> ??????????????? set $sigsegv_Known = 1
> ??????????? end
> ??????? end
>
> ??????? if ($sigsegv_Known)
> ??????????? continue
> ??????? end
> ????end
> end
This shouldn't be necessary when using gdb on linux. I've always found 
the "handle SIGSEGV" command to be sufficient. However, the downside of 
"handle SIGSEGV" is that gdb won't stop if you hit an actually crash. So 
your script might be useful in this situation, although it does seem a 
bit tenuous and is probably not covering all cases were hotspot might 
trap. For example, is it handling compiler uncommon traps?

cheers,

Chris

From bob.vandette at oracle.com  Tue Sep 10 20:44:43 2019
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 10 Sep 2019 16:44:43 -0400
Subject: RFR: 8229202 - Docker reporting causes secondary crashes in error
 handling
Message-ID: <67C2BCEA-FFAE-4C86-B0EF-37EF802AFB19@oracle.com>

Please review this fix for a secondary failure occurring during hotspot error reporting.
If hotspot encounters a failure in the early VM initialization, the container initialization 
will not have been completed causing an assert in the is_containerized function.

The proposed fix will cause the error reporting to not list any container configuration data
since _is_containerized defaults to false.  


BUG: 
https://bugs.openjdk.java.net/browse/JDK-8229202

PROPOSED FIX:

diff --git a/src/hotspot/os/linux/osContainer_linux.hpp b/src/hotspot/os/linux/osContainer_linux.hpp
--- a/src/hotspot/os/linux/osContainer_linux.hpp
+++ b/src/hotspot/os/linux/osContainer_linux.hpp
@@ -62,7 +62,6 @@
 };
 
 inline bool OSContainer::is_containerized() {
-  assert(_is_initialized, "OSContainer not initialized");
   return _is_containerized;
 }
 

Bob.


From harold.seigel at oracle.com  Tue Sep 10 21:03:22 2019
From: harold.seigel at oracle.com (Harold Seigel)
Date: Tue, 10 Sep 2019 17:03:22 -0400
Subject: RFR: 8229202 - Docker reporting causes secondary crashes in error
 handling
In-Reply-To: <67C2BCEA-FFAE-4C86-B0EF-37EF802AFB19@oracle.com>
References: <67C2BCEA-FFAE-4C86-B0EF-37EF802AFB19@oracle.com>
Message-ID: <bdc9b312-574f-b7a7-d82a-dde7b8793a64@oracle.com>

Looks good.

Thanks, Harold

On 9/10/2019 4:44 PM, Bob Vandette wrote:
> Please review this fix for a secondary failure occurring during hotspot error reporting.
> If hotspot encounters a failure in the early VM initialization, the container initialization
> will not have been completed causing an assert in the is_containerized function.
>
> The proposed fix will cause the error reporting to not list any container configuration data
> since _is_containerized defaults to false.
>
>
> BUG:
> https://bugs.openjdk.java.net/browse/JDK-8229202
>
> PROPOSED FIX:
>
> diff --git a/src/hotspot/os/linux/osContainer_linux.hpp b/src/hotspot/os/linux/osContainer_linux.hpp
> --- a/src/hotspot/os/linux/osContainer_linux.hpp
> +++ b/src/hotspot/os/linux/osContainer_linux.hpp
> @@ -62,7 +62,6 @@
>   };
>   
>   inline bool OSContainer::is_containerized() {
> -  assert(_is_initialized, "OSContainer not initialized");
>     return _is_containerized;
>   }
>   
>
> Bob.
>

From david.holmes at oracle.com  Tue Sep 10 21:44:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2019 07:44:15 +1000
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
Message-ID: <297ffc9c-4960-b6d7-e92c-5c5f2e5426ef@oracle.com>

Hi Leo,

Looks fine.

Thanks,
David

On 10/09/2019 11:39 pm, Leo Korinth wrote:
> 
> 
> On 02/09/2019 22:38, Kim Barrett wrote:
>>> On Sep 2, 2019, at 9:06 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>
>>> Hi!
>>>
>>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is 
>>> unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This 
>>> is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>>
>>> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp 
>>> does (in addition to NULL the pointer) also set a counter to zero. 
>>> Although my change "looks" correct, I tried follow the usage of 
>>> deallocate_counters(), and could not find a call site. Should I 
>>> create a bug on this, or am I missing something here?
>>
>> Your modification to deallocate_counters looks fine.? I don't think
>> you are missing anything, I think it's not called.? That does look
>> like it might be a (pre-existing) bug.? Maybe they are immortal?? But
>> that isn't obvious from a quick skim.
>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8230398
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~lkorinth/8230398
>>>
>>> Testing:
>>> mach5 tier1-3
>>>
>>> Thanks,
>>> Leo
>>
>> ------------------------------------------------------------------------------ 
>>
>>
>> [pre-existing]
>> There are some destructors that are unnecessarily nulling out members
>> after deleting their values, such as here:
>>
>> src/hotspot/share/classfile/classLoader.cpp
>> ? 387?? FREE_C_HEAP_ARRAY(const char, _name);
>> ? 388?? _name = NULL;
>>
>> src/hotspot/share/gc/g1/sparsePRT.cpp
>> 106 RSHashTable::~RSHashTable() {
>>
>> src/hotspot/share/gc/shared/cardTableRS.cpp
>> 626 CardTableRS::~CardTableRS() {
>>
>> src/hotspot/share/runtime/thread.cpp
>> 1330 NamedThread::~NamedThread() {
>>
>> Your call whether you want to do anything about these with this change.
>>
>> ------------------------------------------------------------------------------ 
>>
>>
>> Other than that, looks good.? I don't need another webrev if you
>> decide to remove the above assignments to NULL near code you were
>> already changing.? A more extensive pass for such should perhaps be a
>> separate change.
>>
> I will remove NULL assignments of fields in destructors and keep them 
> otherwise.
> 
> I will also add a comment (// handles NULL pointers) to FreeHeap and 
> os::free to not only describe behaviour, but also to establish a contract.
> 
> Also fixed indentation miss in os_perf_windows.cpp
> 
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
> 
> Full:
> http://cr.openjdk.java.net/~lkorinth/8230398/01
> 
> 
> running tests...

From mikhailo.seledtsov at oracle.com  Tue Sep 10 22:00:14 2019
From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com)
Date: Tue, 10 Sep 2019 15:00:14 -0700
Subject: RFR: 8229202 - Docker reporting causes secondary crashes in error
 handling
In-Reply-To: <bdc9b312-574f-b7a7-d82a-dde7b8793a64@oracle.com>
References: <67C2BCEA-FFAE-4C86-B0EF-37EF802AFB19@oracle.com>
 <bdc9b312-574f-b7a7-d82a-dde7b8793a64@oracle.com>
Message-ID: <bfa171dd-b3aa-ae8e-f053-6437ecf047fe@oracle.com>

+1

On 9/10/19 2:03 PM, Harold Seigel wrote:
> Looks good.
>
> Thanks, Harold
>
> On 9/10/2019 4:44 PM, Bob Vandette wrote:
>> Please review this fix for a secondary failure occurring during 
>> hotspot error reporting.
>> If hotspot encounters a failure in the early VM initialization, the 
>> container initialization
>> will not have been completed causing an assert in the 
>> is_containerized function.
>>
>> The proposed fix will cause the error reporting to not list any 
>> container configuration data
>> since _is_containerized defaults to false.
>>
>>
>> BUG:
>> https://bugs.openjdk.java.net/browse/JDK-8229202
>>
>> PROPOSED FIX:
>>
>> diff --git a/src/hotspot/os/linux/osContainer_linux.hpp 
>> b/src/hotspot/os/linux/osContainer_linux.hpp
>> --- a/src/hotspot/os/linux/osContainer_linux.hpp
>> +++ b/src/hotspot/os/linux/osContainer_linux.hpp
>> @@ -62,7 +62,6 @@
>> ? };
>> ? ? inline bool OSContainer::is_containerized() {
>> -? assert(_is_initialized, "OSContainer not initialized");
>> ??? return _is_containerized;
>> ? }
>>
>> Bob.
>>

From daniel.daugherty at oracle.com  Tue Sep 10 22:19:54 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 10 Sep 2019 18:19:54 -0400
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <f52eaf30-f804-eb0a-7cc9-faf3dadddb0c@oracle.com>
 <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com>
 <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
 <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
Message-ID: <81d11a97-49f8-c61b-b31d-b6f6d1fd2e54@oracle.com>

On 9/9/19 8:45 AM, Robbin Ehn wrote:
> Hi all,
>
> Me and Erik had some offline discussions, which ended up in this 
> incremental change:
> http://cr.openjdk.java.net/~rehn/8226705/v2/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v2/full/webrev/

Thanks for coming back to this change! I know it has been a
difficult one...

Going with the full webrev since it has been so long since I looked
at the original changes:

src/hotspot/share/aot/aotCodeHeap.cpp
 ??? No comments.

src/hotspot/share/aot/aotCompiledMethod.cpp
 ??? No comments.

src/hotspot/share/aot/aotCompiledMethod.hpp
 ??? Hmmm... No changes to this file.

src/hotspot/share/ci/ciEnv.cpp
 ??? No comments.

src/hotspot/share/code/codeCache.cpp
 ??? No comments.

src/hotspot/share/code/compiledMethod.cpp
 ??? No comments.

src/hotspot/share/code/compiledMethod.hpp
 ??? No comments.

src/hotspot/share/code/nmethod.cpp
 ??? No comments.

src/hotspot/share/code/nmethod.hpp
 ??? No comments.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp
 ??? No comments.

src/hotspot/share/gc/z/zNMethod.cpp
 ??? No comments.

src/hotspot/share/jvmci/jvmciEnv.cpp
 ??? No comments.

src/hotspot/share/jvmci/jvmciRuntime.cpp
 ??? No comments.

src/hotspot/share/oops/instanceKlass.cpp
 ??? No comments.

src/hotspot/share/oops/method.cpp
 ??? No comments.

src/hotspot/share/oops/method.hpp
 ??? No comments.

src/hotspot/share/prims/jvmtiEventController.cpp
 ??? No comments.

src/hotspot/share/prims/methodHandles.cpp
 ??? No comments.

src/hotspot/share/prims/whitebox.cpp
 ??? No comments.

src/hotspot/share/runtime/biasedLocking.cpp
 ??? L729: void BiasedLocking::revoke_own_locks(Handle obj, TRAPS) {
 ??????? Perhaps add:
 ????????? assert(THREAD->is_Java_thread(), "must be called by a 
JavaThread");
 ????????? JavaThread* thread = (JavaThread*)THREAD;

 ??????? and then switch uses of 'THREAD' for 'thread'. This way we
 ??????? are not casting away a bad caller...

src/hotspot/share/runtime/biasedLocking.hpp
 ??? L193: ? // This should be called by a JavaThread to revoke the bias 
of an owned object
 ??????? Perhaps:
 ??????????? // This must only be called by a JavaThread to revoke the 
bias of an owned object.

src/hotspot/share/runtime/deoptimization.cpp
 ??? Moving the top part of Deoptimization::fetch_unroll_info_helper()
 ??? made this hard to review, but I suspect leaving it in place would
 ??? have been just as hard because of the refactor of code into
 ??? eliminate_allocations() and eliminate_locks(). Did lots of
 ??? scrolling of the frames windows and I think it looks correct...

src/hotspot/share/runtime/deoptimization.hpp
 ??? L152: ? static void deoptimize(JavaThread* thread, frame fr, 
RegisterMap *reg_map, DeoptReason reason = Reason_constraint);
 ??????? I'm not fond of default parameters, but I'll live... :-)

src/hotspot/share/runtime/mutex.hpp
 ??? old L67: ?????? special??????? = tty??????????? +?? 1,
 ??? new L67: ?????? special??????? = tty??????????? +?? 2,
 ??????? I'll be _so glad_ when the lock ranking stuff is cleaned up!

 ??? No (non-whiny) comments. :-)

src/hotspot/share/runtime/mutexLocker.cpp
 ??? L236: ? def(CompiledMethod_lock????????? , PaddedMutex? , 
special-1,?? true,? Monitor::_safepoint_check_never);
 ??????? So CompiledMethod_lock is 'tty' + 1. Is that so that it ranks
 ??????? lower than the Patching_lock? Any lock ranking issues expected
 ??????? for the places you replaced Patching_lock with CompiledMethod_lock?

 ??????? I don't think you replaced all uses of Patching_lock, right?
 ??????? (Sorry if I asked that before...)

 ??? old L251: ? def(OsrList_lock???????????????? , PaddedMutex? , 
leaf,??????? true,? Monitor::_safepoint_check_never);
 ??????? So OsrList_lock was a 'leaf' and you've replaced its uses with
 ??????? CompiledMethod_lock which is (special - 1). I'm assuming that
 ??????? no lock ranking hiccups have been seen...

src/hotspot/share/runtime/mutexLocker.hpp
 ??? L35: extern Mutex*?? CompiledMethod_lock;???????????? // a lock 
used to guard a compiled method
 ??????? Should you also mention the OSR queues since CompiledMethod_lock
 ??????? also replaced this:

 ??????? old L93: extern Mutex*?? OsrList_lock; // a lock used to 
serialize access to OSR queues

src/hotspot/share/runtime/sharedRuntime.cpp
 ??? No comments.

src/hotspot/share/runtime/thread.cpp
 ??? No comments.

src/hotspot/share/runtime/thread.hpp
 ??? No comments.

src/hotspot/share/runtime/tieredThresholdPolicy.cpp
 ??? No comments.

src/hotspot/share/runtime/vmOperations.cpp
 ??? No comments.

src/hotspot/share/runtime/vmOperations.hpp
 ??? No comments (another VM_Op bites the dust...)

src/hotspot/share/services/dtraceAttacher.cpp
 ??? No comments other than: Such a strange place to find the
 ??? VM_DeoptimizeTheWorld VM_Op...

test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java
 ??? Shouldn't there be an @bug 8226705 with the new test?

 ??? What tier does the new test execute in and have you verified
 ??? that it passes on all Oracle platforms?

You'll definitely want a review from a Compiler team member
for this one. :-) Since there are Biased Locking changes,
Patricio should also chime in here.

For testing, I'm assuming that the tests that failed due to

 ??? JDK-8221734 Deoptimize with handshakes

have been run on this REDO and that they pass.


Thumbs up! I don't need to see another webrev if you decide to
make any changes due to my few comments above.

Dan


>
> The problem is a nmethods state must never go backwards.
> When the methods code is set to the compiled code it can be made 
> not_entrant.
> (it can be set to not_entrant before not having Compiled_lock)
> When unlinking the methods code must point to the nmethod.
>
> If we set code before changing state, it can go backwards.
> If we set state before setting code, we can't unlink it.
>
> This solution uses the new CompiledMethod_lock to synchronize code and 
> state changes. (unloaded don't need the lock since it require a 
> safepoint to happen)
>
> But this resulted in a circular lock issue with OsrList_lock.
> Therefore OsrList_lock is removed, instead we use CompiledMethod_lock.
>
> After this patch it should be possible to remove Compile_lock from 
> some paths. (Note that JVMCI is missing Compile_lock from several 
> pathes, but fewer with this changeset)
>
> Also InterpreterRuntime::frequency_counter_overflow_inner seem to have 
> the same bug as the reason for this redo: 
> BiasedLocking::revoke(objects_to_revoke, thread);
> The objects could have been rebaised by the time we return from it.
> I think we should call the new 
> BiasedLocking::revoke_own_locks(objects_to_revoke->at(i), thread); 
> here also.
>
> Passes t1-5 twice and KS 60 min.
>
> @Erik I stayed with current is_in_use (not_installed + in_use), there 
> were to many places and many of them needed an equivalent method if 
> is_in_use was to be changed (to only in_use). I didn't see any issue 
> with using the current definition.
>
> Thanks, Robbin
>
> On 8/29/19 4:35 PM, Erik ?sterlund wrote:
>> Hi Robbin,
>>
>> On 2019-08-29 14:25, Robbin Ehn wrote:
>>> Hi Erik, thanks for having a look.
>>>
>>> Just some short answers and questions.
>>>
>>> On 8/29/19 12:01 PM, Erik ?sterlund wrote:
>>>> Hi Robbin,
>>>>
>>>> Glad to see this work making it back again. Last time this patch 
>>>> was proposed, there were no guards against non-monotonic nmethod 
>>>> state transitions. Today there are (since 
>>>> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, 
>>>> if you call make_not_entrant() on an nmethod that has racingly 
>>>> become zombie, it is today impossible to resurrect that nmethod. 
>>>> Instead, make_not_entrant() will return false.
>>>
>>> Great, I'll have a look.
>>>
>>>>
>>>> In particular, I think that is what the following code in the patch 
>>>> is guarding against (in codeCache.cpp):
>>>>
>>>> 1150 // Mark methods for deopt (if safe or possible).
>>>> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() {
>>>> 1152?? MutexLocker mu(CodeCache_lock, 
>>>> Mutex::_no_safepoint_check_flag);
>>>> 1153?? CompiledMethodIterator 
>>>> iter(CompiledMethodIterator::only_alive_and_not_unloading);
>>>> 1154?? while(iter.next()) {
>>>> 1155???? CompiledMethod* nm = iter.method();
>>>> 1156???? if (!nm->method()->is_method_handle_intrinsic() &&
>>>> 1157???????? !nm->is_not_installed() &&
>>>> 1158???????? nm->is_in_use() &&
>>>> 1159???????? !nm->is_native_method()) {
>>>> 1160?????? // Intrinsics and native methods are never deopted. A 
>>>> method that is
>>>> 1161?????? // not installed yet or is not in use is not safe to 
>>>> deopt; the
>>>> 1162?????? // is_in_use() check covers the not_entrant and not 
>>>> zombie cases.
>>>> 1163?????? // Note: A not_entrant method can become a zombie at 
>>>> anytime if it was
>>>> 1164?????? // made not_entrant before the previous 
>>>> safepoint/handshake.
>>>> 1165?????? nm->mark_for_deoptimization();
>>>> 1166???? }
>>>> 1167?? }
>>>> 1168 }
>>>>
>>>> In fact, this code is also guarding against is_not_installed 
>>>> nmethods (which was introduced as a new function). If we find that 
>>>> an nmethod is bad and say it needs deoptimization, and that nmethod 
>>>> is just about to get installed, it seems to me that skipping that 
>>>> nmethod and not making it not entrant is really dangerous and will 
>>>> eventually lead to a crash. Because in ciEnv.cpp we set_code to the 
>>>> about to be installed nmethod, and it will get called without 
>>>> anything stopping the invalid code from being executed by mutators, 
>>>> and it was being invalidated for a reason. So basically we really 
>>>> do have to make these not entrant, or we will blow up.
>>>>
>>>> I guess the reason you needed this check is because make_in_use() 
>>>> doesn't check what the current state is, causing monotonicity 
>>>> problems, making a potentially already not entrant nmethod become 
>>>> in_use, eventually blowing up asserts and probably the VM. 
>>>> Regrettably, make_in_use() still does that, because I had no need 
>>>> for changing it to use nmethod::try_transition in 8224674, nobody 
>>>> previously could find these nmethods. In retrospect, not changing 
>>>> that was a bit silly. So if we just change make_in_use() to use 
>>>> nmethod::try_transition instead, then you can remove the 
>>>> !is_not_installed check... which I argue we have to do. The reason 
>>>> we never ran in to this before is because we made the nmethods not 
>>>> entrant in a safepoint, and between making an nmethod and making it 
>>>> in_use, there is no safepoint check, so they were never observed in 
>>>> this state.
>>>>
>>>
>>> Yes, thread A is creating a new method X, it have state not installed.
>>> If we make method X not entrant, Thread A will flip it back to 
>>> in_use, which bad
>>> and we crash. mark_all_nmethods_for_deoptimization is a test method 
>>> used in the
>>> new jtreg test, which is the only use (I see dtrace have some hack 
>>> to use it, it
>>> can crash the vm).
>>
>> Exactly. However, what you are missing here is that this does not 
>> happen only for the whitebox test, now that we do normal deopt with 
>> handshakes.
>>
>> Consider the following race.
>>
>> A compiler thread compiles a new nmethod. In this nmethod, it's 
>> assumed that a certain invoke_virtual callsite is completely 
>> monomorphic, and the compiler chooses to implement the callsite with 
>> a direct call, which is only valid given its monomorphism. The 
>> compilation finishes, and at the very end of the process, the code 
>> cache lock is grabbed, under which we allocate the new nmethod, 
>> verify the assumptions made (which still hold), inject entries in 
>> DependencyContexts so that if these assumptions change, we will 
>> deopt, and then unlock the code cache lock. The nmethod is now still 
>> in the state not_installed.
>>
>> What can happen now is that another thread loads a class that makes 
>> the callsite potentially megamorphic. Deopt is triggered, walking the 
>> dependency contexts under the CodeCache_lock, marking things that are 
>> now bad. In this list we will find the newly compiled nmethod that 
>> has not been made in_use yet. It is marked for deoptimization. Then 
>> the Deoptimization::deoptimize_all_marked() function is called to 
>> make sure that we 1) make all the marked nmethods not_entrant, and 2) 
>> arm the bad activation records in the stack. Now the first step of 
>> the two grabs the code cache lock, and walks the code cache. It finds 
>> our about to be installed nmethod, and shoots make_not_entrant() at 
>> it, racing with the compiler thread calling make_in_use() on it.
>>
>> This is why I advocate an approach where we simply make it safe to 
>> call make_in_use() racing with make_not_entrant(), instead of trying 
>> to chase down all possible scenarios in which this can happen. I can 
>> imagine a number of others, now that deoptimization is being done 
>> with handshakes.
>>
>>>> ... and similarly here:
>>>>
>>>> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) {
>>>> 1193?????? // only_alive_and_not_unloading() can return not_entrant 
>>>> nmethods.
>>>> 1194?????? // A not_entrant method can become a zombie at anytime 
>>>> if it was
>>>> 1195?????? // made not_entrant before the previous 
>>>> safepoint/handshake. The
>>>> 1196?????? // is_in_use() check covers the not_entrant and not 
>>>> zombie cases
>>>> 1197?????? // that have become true after the method was marked for 
>>>> deopt.
>>>> 1198?????? nm->make_not_entrant();
>>>> 1199???? }
>>>>
>>>> ... we now don't need the guard against is_in_use() here.
>>>
>>> Here we don't need that, but we don't need !nm->is_not_entrant() 
>>> either, since
>>> it would return false as you say!?
>>
>> Indeed. All state checks to see if it is even safe to call the state 
>> transition function should be removed, as it should always be safe.
>>
>>> If we should have an early filter it think nm->is_in_use() is 
>>> clearer than:
>>> not not entrant ;) (since the not_installed is normally not seen here)
>>
>> The transitioning functions themselves already have early checks, so 
>> there really is nothing to gain from checking if we should transition 
>> first and then doing it.
>>
>>>>
>>>> For what I propose to work out, we need to change 
>>>> nmethod::make_in_use to use nmethod::try_transition, and 
>>>> AOTCompiledMethod::make_entrant() needs to also return false when 
>>>> encountering a not_entrant nmethod, enforcing monotonicity, instead 
>>>> of asserting about that. AOT methods may turn not_in_use AOT 
>>>> methods to in_use, but not not_entrant to in_use. Once not_entrant, 
>>>> an AOT methods should remain not entrant forever.
>>>
>>> The only time we see methods which are not installed should be 
>>> methods that will
>>> never be deoptimize (except when calling the test method
>>> mark_all_nmethods_for_deoptimization), intrinsic and native.
>>
>> That's not right. It's visible to a bunch of deoptimizations.
>>
>>> And if I remember correctly make_in_use is called in a constructor 
>>> which
>>> requires extra error-handling. Construction would fail if 
>>> try_transition failed.
>>> The assumption about these 'never deopted' methods seem to be just 
>>> that :)
>>
>> That is also not right. We grab the code cache lock, create the 
>> nmethod, verify dependencies, install dependencies, drop the code 
>> cache lock, all under not_installed. It's only after linking the 
>> Method to the code, that we eventually set it to in_use. So it's 
>> visible for longer than you thought. And it's visible to calls, a 
>> small instant before we change the state to in_use(). That's what I 
>> claim isn't right. We don't want to be able to call into these guys.
>>
>>>>
>>>> So basically, these guards are for something that used to be racy 
>>>> and dangerous due to the lack of guards inside of the state 
>>>> transitions, and today that is completely harmless, as the proper 
>>>> guards are in the attempts to change state. I would prefer to 
>>>> remove these guards, as it is confusing to the reader that we are 
>>>> guarding against a problem that can't happen. So I think you can 
>>>> remove the various checks for what state the nmethod is in, the 
>>>> comments describing races, and just keep the checks if it's a 
>>>> method handle intrinsic or native method.
>>>
>>> I'll revisit this. Was a few months since I did this.
>>
>> Okay!
>>
>>>>
>>>> In deoptimize.cpp, the fetch_unroll_info_helper function has moved 
>>>> down, making it difficult to review as shows the code delta as if 
>>>> everything changed. So I can't see what actually changed there. :( 
>>>> Would you mind moving that code back so the webrev shows what 
>>>> changed there?
>>>
>>> I have inserted two new static functions before 
>>> fetch_unroll_info_helper,
>>> since code from fetch_unroll_info_helper are in these functions diff 
>>> do this.
>>> They are static function they are best off before, and putting after 
>>> them I
>>> don't think would help the diff tool + I need fwd decl.
>>> Suggestion?
>>
>> Okay, I will try to work out what the actual diff is manually.
>>
>> Thanks,
>> /Erik
>>
>>> Thanks, Robbin
>>>
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>> On 2019-08-28 11:57, Robbin Ehn wrote:
>>>>> Hi, hotspot-dev was the intended list.
>>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>>> Hi all, please consider,
>>>>>>
>>>>>> To get away from the issues of us revoking in the handshake, but 
>>>>>> before deopt
>>>>>> the locks get re-biased before we hit deopt handler, we instead 
>>>>>> revoke in deopt
>>>>>> handler.
>>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>>>>> revoke after
>>>>>> that but before we start looking at the monitors, with a 
>>>>>> NoSafepointVerifier.
>>>>>>
>>>>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>>>>> merge conflicts
>>>>>> some pieces did not apply:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>>>>
>>>>>> So this is what was reviewed.
>>>>>>
>>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>>
>>>>>> Bug 8224795 fix is here:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>>>
>>>>>>
>>>>>> After this we have the same functionally as the reverted change-set.
>>>>>>
>>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>>>>
>>>>>>
>>>>>> This code was messy adding the deopt revocation in 3 places made 
>>>>>> it worse.
>>>>>> Here is a refactoring of that code. (also removed a dead method 
>>>>>> in biasedlocking):
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>>
>>>>>> And here is full:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>>
>>>>>> Also a full squashed patch file:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>>
>>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, 
>>>>>> MacOSX still
>>>>>> running.
>>>>>>
>>>>>> Thanks, Robbin
>>>>>>
>>>>>>


From kim.barrett at oracle.com  Tue Sep 10 23:33:12 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 10 Sep 2019 19:33:12 -0400
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
Message-ID: <CB8A97E0-3FB3-4209-A38E-1FEA20383D97@oracle.com>

> On Sep 10, 2019, at 9:39 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
> 
> I will remove NULL assignments of fields in destructors and keep them otherwise.
> 
> I will also add a comment (// handles NULL pointers) to FreeHeap and os::free to not only describe behaviour, but also to establish a contract.
> 
> Also fixed indentation miss in os_perf_windows.cpp
> 
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
> 
> Full:
> http://cr.openjdk.java.net/~lkorinth/8230398/01
> 
> 
> running tests...

Looks good.


From christian.hagedorn at oracle.com  Wed Sep 11 05:19:13 2019
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Wed, 11 Sep 2019 07:19:13 +0200
Subject: [14] RFR(XS): 8230762: Change MacroAssembler::debug32/64 to use
 fatal instead of assert
In-Reply-To: <11291ca4-72da-86df-87a9-f529de336c06@oracle.com>
References: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
 <11291ca4-72da-86df-87a9-f529de336c06@oracle.com>
Message-ID: <e4c1f4e3-2a4e-3a96-9109-114d27e76910@oracle.com>

Hi Vladimir

Thanks for your review!

Best regards,
Christian

On 10.09.19 10:49, Vladimir Ivanov wrote:
> x86 part looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 09/09/2019 17:14, Christian Hagedorn wrote:
>> Hi
>>
>> Please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8230762
>> http://cr.openjdk.java.net/~chagedorn/8230762/webrev.00/
>>
>> The webrev is based on JDK-8225653. MacroAssembler::debug32/64 is 
>> changed such that the last operation is fatal(). I think that some 
>> additional instructions like ThreadStateTransition::transition or 
>> tty->print_cr are then not needed anymore. I also ensured that after 
>> each debug32/64 call a hlt is directly emitted (which was required in 
>> generate_verify_oop - in MacroAssembler::stop we already have a hlt 
>> instruction afterwards).
>>
>> Thank you!
>>
>> Best regards,
>> Christian

From devnexen at gmail.com  Wed Sep 11 05:27:41 2019
From: devnexen at gmail.com (David CARLIER)
Date: Wed, 11 Sep 2019 06:27:41 +0100
Subject: [PATCH] Darwin, option to monitor anonymous pages
Message-ID: <CA+XhMqzaRzAb1pKW+Lmph3vcwT7UHKUBB791apBC1XmzryQTKQ@mail.gmail.com>

> This patch add a product flag which requires additional processes to be
> followed. Changes to product flags require a CSR request [1] to be filed
> and approved. Without an author/committer to actively work with you to
> get these patches through the process they will likely just languish on
> the mailing list.

> David H.

Thanks for letting me know I had pushed to csr-discuss w/o much
success (ie mail did not pass filters) we shall see !
Regards.

From david.holmes at oracle.com  Wed Sep 11 05:38:37 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2019 15:38:37 +1000
Subject: [PATCH] Darwin, option to monitor anonymous pages
In-Reply-To: <CA+XhMqzaRzAb1pKW+Lmph3vcwT7UHKUBB791apBC1XmzryQTKQ@mail.gmail.com>
References: <CA+XhMqzaRzAb1pKW+Lmph3vcwT7UHKUBB791apBC1XmzryQTKQ@mail.gmail.com>
Message-ID: <dac97f36-fad9-9a74-144b-b8bc571ef014@oracle.com>

On 11/09/2019 3:27 pm, David CARLIER wrote:
>> This patch add a product flag which requires additional processes to be
>> followed. Changes to product flags require a CSR request [1] to be filed
>> and approved. Without an author/committer to actively work with you to
>> get these patches through the process they will likely just languish on
>> the mailing list.
> 
>> David H.
> 
> Thanks for letting me know I had pushed to csr-discuss w/o much
> success (ie mail did not pass filters) we shall see !

Not sure what you mean by "pushed to csr-discuss". csr-discuss is a 
mailing list for discussing the CSR process. You need to have a CSR 
request filed in JBS, alongside the JBS issue for this enhancement 
request. For that you need an OpenJDK author (or above) to work with you 
to files those JBS issues sponsor the change.

David

> Regards.
> 

From devnexen at gmail.com  Wed Sep 11 05:57:39 2019
From: devnexen at gmail.com (David CARLIER)
Date: Wed, 11 Sep 2019 06:57:39 +0100
Subject: [PATCH] Darwin, option to monitor anonymous pages
In-Reply-To: <dac97f36-fad9-9a74-144b-b8bc571ef014@oracle.com>
References: <CA+XhMqzaRzAb1pKW+Lmph3vcwT7UHKUBB791apBC1XmzryQTKQ@mail.gmail.com>
 <dac97f36-fad9-9a74-144b-b8bc571ef014@oracle.com>
Message-ID: <CA+XhMqz9FqMpm9=xJkW73DLVrXBAr5ZmBujpz0BPvN0mCyH_jA@mail.gmail.com>

Oh right I see good to know ! Thanks.

On Wed, 11 Sep 2019 at 06:38, David Holmes <david.holmes at oracle.com> wrote:
>
> On 11/09/2019 3:27 pm, David CARLIER wrote:
> >> This patch add a product flag which requires additional processes to be
> >> followed. Changes to product flags require a CSR request [1] to be filed
> >> and approved. Without an author/committer to actively work with you to
> >> get these patches through the process they will likely just languish on
> >> the mailing list.
> >
> >> David H.
> >
> > Thanks for letting me know I had pushed to csr-discuss w/o much
> > success (ie mail did not pass filters) we shall see !
>
> Not sure what you mean by "pushed to csr-discuss". csr-discuss is a
> mailing list for discussing the CSR process. You need to have a CSR
> request filed in JBS, alongside the JBS issue for this enhancement
> request. For that you need an OpenJDK author (or above) to work with you
> to files those JBS issues sponsor the change.
>
> David
>
> > Regards.
> >

From patricio.chilano.mateo at oracle.com  Wed Sep 11 06:07:50 2019
From: patricio.chilano.mateo at oracle.com (Patricio Chilano)
Date: Wed, 11 Sep 2019 03:07:50 -0300
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <f52eaf30-f804-eb0a-7cc9-faf3dadddb0c@oracle.com>
 <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com>
 <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
 <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
Message-ID: <11c23e92-a913-1b1b-70e3-ae973b731ac5@oracle.com>

Hi Robbin,

Thanks for looking into this and for making fetch_unroll_info_helper() 
more clear to read!
I looked again at the biased locking part only since I don't really know 
the rest of code. Those look good to me, just some comments:

src/hotspot/share/runtime/deoptimization.cpp:
1) What was the problem of calling revoke_from_deopt_handler() before 
eliminate_allocations()?
2) If COMPILER2_OR_JVMCI is 0, shouldn't we still call 
revoke_from_deopt_handler()?

src/hotspot/share/runtime/biasedLocking.cpp:
L737: markWord prototype_header = k->prototype_header();
Although that will probably get optimized away in product code, I would 
just place that load inside the assert.

src/hotspot/share/runtime/biasedLocking.xpp:
Maybe s/revoke_own_locks()/revoke_own_lock() ?

Regarding InterpreterRuntime::frequency_counter_overflow_inner() having 
possibly the same bug, not sure I see the trace for that.

Thanks!
Patricio

On 9/9/19 9:45 AM, Robbin Ehn wrote:
> Hi all,
>
> Me and Erik had some offline discussions, which ended up in this 
> incremental change:
> http://cr.openjdk.java.net/~rehn/8226705/v2/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v2/full/webrev/
>
> The problem is a nmethods state must never go backwards.
> When the methods code is set to the compiled code it can be made 
> not_entrant.
> (it can be set to not_entrant before not having Compiled_lock)
> When unlinking the methods code must point to the nmethod.
>
> If we set code before changing state, it can go backwards.
> If we set state before setting code, we can't unlink it.
>
> This solution uses the new CompiledMethod_lock to synchronize code and 
> state changes. (unloaded don't need the lock since it require a 
> safepoint to happen)
>
> But this resulted in a circular lock issue with OsrList_lock.
> Therefore OsrList_lock is removed, instead we use CompiledMethod_lock.
>
> After this patch it should be possible to remove Compile_lock from 
> some paths. (Note that JVMCI is missing Compile_lock from several 
> pathes, but fewer with this changeset)
>
> Also InterpreterRuntime::frequency_counter_overflow_inner seem to have 
> the same bug as the reason for this redo: 
> BiasedLocking::revoke(objects_to_revoke, thread);
> The objects could have been rebaised by the time we return from it.
> I think we should call the new 
> BiasedLocking::revoke_own_locks(objects_to_revoke->at(i), thread); 
> here also.
>
> Passes t1-5 twice and KS 60 min.
>
> @Erik I stayed with current is_in_use (not_installed + in_use), there 
> were to many places and many of them needed an equivalent method if 
> is_in_use was to be changed (to only in_use). I didn't see any issue 
> with using the current definition.
>
> Thanks, Robbin
>
> On 8/29/19 4:35 PM, Erik ?sterlund wrote:
>> Hi Robbin,
>>
>> On 2019-08-29 14:25, Robbin Ehn wrote:
>>> Hi Erik, thanks for having a look.
>>>
>>> Just some short answers and questions.
>>>
>>> On 8/29/19 12:01 PM, Erik ?sterlund wrote:
>>>> Hi Robbin,
>>>>
>>>> Glad to see this work making it back again. Last time this patch 
>>>> was proposed, there were no guards against non-monotonic nmethod 
>>>> state transitions. Today there are (since 
>>>> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, 
>>>> if you call make_not_entrant() on an nmethod that has racingly 
>>>> become zombie, it is today impossible to resurrect that nmethod. 
>>>> Instead, make_not_entrant() will return false.
>>>
>>> Great, I'll have a look.
>>>
>>>>
>>>> In particular, I think that is what the following code in the patch 
>>>> is guarding against (in codeCache.cpp):
>>>>
>>>> 1150 // Mark methods for deopt (if safe or possible).
>>>> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() {
>>>> 1152?? MutexLocker mu(CodeCache_lock, 
>>>> Mutex::_no_safepoint_check_flag);
>>>> 1153?? CompiledMethodIterator 
>>>> iter(CompiledMethodIterator::only_alive_and_not_unloading);
>>>> 1154?? while(iter.next()) {
>>>> 1155???? CompiledMethod* nm = iter.method();
>>>> 1156???? if (!nm->method()->is_method_handle_intrinsic() &&
>>>> 1157???????? !nm->is_not_installed() &&
>>>> 1158???????? nm->is_in_use() &&
>>>> 1159???????? !nm->is_native_method()) {
>>>> 1160?????? // Intrinsics and native methods are never deopted. A 
>>>> method that is
>>>> 1161?????? // not installed yet or is not in use is not safe to 
>>>> deopt; the
>>>> 1162?????? // is_in_use() check covers the not_entrant and not 
>>>> zombie cases.
>>>> 1163?????? // Note: A not_entrant method can become a zombie at 
>>>> anytime if it was
>>>> 1164?????? // made not_entrant before the previous 
>>>> safepoint/handshake.
>>>> 1165?????? nm->mark_for_deoptimization();
>>>> 1166???? }
>>>> 1167?? }
>>>> 1168 }
>>>>
>>>> In fact, this code is also guarding against is_not_installed 
>>>> nmethods (which was introduced as a new function). If we find that 
>>>> an nmethod is bad and say it needs deoptimization, and that nmethod 
>>>> is just about to get installed, it seems to me that skipping that 
>>>> nmethod and not making it not entrant is really dangerous and will 
>>>> eventually lead to a crash. Because in ciEnv.cpp we set_code to the 
>>>> about to be installed nmethod, and it will get called without 
>>>> anything stopping the invalid code from being executed by mutators, 
>>>> and it was being invalidated for a reason. So basically we really 
>>>> do have to make these not entrant, or we will blow up.
>>>>
>>>> I guess the reason you needed this check is because make_in_use() 
>>>> doesn't check what the current state is, causing monotonicity 
>>>> problems, making a potentially already not entrant nmethod become 
>>>> in_use, eventually blowing up asserts and probably the VM. 
>>>> Regrettably, make_in_use() still does that, because I had no need 
>>>> for changing it to use nmethod::try_transition in 8224674, nobody 
>>>> previously could find these nmethods. In retrospect, not changing 
>>>> that was a bit silly. So if we just change make_in_use() to use 
>>>> nmethod::try_transition instead, then you can remove the 
>>>> !is_not_installed check... which I argue we have to do. The reason 
>>>> we never ran in to this before is because we made the nmethods not 
>>>> entrant in a safepoint, and between making an nmethod and making it 
>>>> in_use, there is no safepoint check, so they were never observed in 
>>>> this state.
>>>>
>>>
>>> Yes, thread A is creating a new method X, it have state not installed.
>>> If we make method X not entrant, Thread A will flip it back to 
>>> in_use, which bad
>>> and we crash. mark_all_nmethods_for_deoptimization is a test method 
>>> used in the
>>> new jtreg test, which is the only use (I see dtrace have some hack 
>>> to use it, it
>>> can crash the vm).
>>
>> Exactly. However, what you are missing here is that this does not 
>> happen only for the whitebox test, now that we do normal deopt with 
>> handshakes.
>>
>> Consider the following race.
>>
>> A compiler thread compiles a new nmethod. In this nmethod, it's 
>> assumed that a certain invoke_virtual callsite is completely 
>> monomorphic, and the compiler chooses to implement the callsite with 
>> a direct call, which is only valid given its monomorphism. The 
>> compilation finishes, and at the very end of the process, the code 
>> cache lock is grabbed, under which we allocate the new nmethod, 
>> verify the assumptions made (which still hold), inject entries in 
>> DependencyContexts so that if these assumptions change, we will 
>> deopt, and then unlock the code cache lock. The nmethod is now still 
>> in the state not_installed.
>>
>> What can happen now is that another thread loads a class that makes 
>> the callsite potentially megamorphic. Deopt is triggered, walking the 
>> dependency contexts under the CodeCache_lock, marking things that are 
>> now bad. In this list we will find the newly compiled nmethod that 
>> has not been made in_use yet. It is marked for deoptimization. Then 
>> the Deoptimization::deoptimize_all_marked() function is called to 
>> make sure that we 1) make all the marked nmethods not_entrant, and 2) 
>> arm the bad activation records in the stack. Now the first step of 
>> the two grabs the code cache lock, and walks the code cache. It finds 
>> our about to be installed nmethod, and shoots make_not_entrant() at 
>> it, racing with the compiler thread calling make_in_use() on it.
>>
>> This is why I advocate an approach where we simply make it safe to 
>> call make_in_use() racing with make_not_entrant(), instead of trying 
>> to chase down all possible scenarios in which this can happen. I can 
>> imagine a number of others, now that deoptimization is being done 
>> with handshakes.
>>
>>>> ... and similarly here:
>>>>
>>>> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) {
>>>> 1193?????? // only_alive_and_not_unloading() can return not_entrant 
>>>> nmethods.
>>>> 1194?????? // A not_entrant method can become a zombie at anytime 
>>>> if it was
>>>> 1195?????? // made not_entrant before the previous 
>>>> safepoint/handshake. The
>>>> 1196?????? // is_in_use() check covers the not_entrant and not 
>>>> zombie cases
>>>> 1197?????? // that have become true after the method was marked for 
>>>> deopt.
>>>> 1198?????? nm->make_not_entrant();
>>>> 1199???? }
>>>>
>>>> ... we now don't need the guard against is_in_use() here.
>>>
>>> Here we don't need that, but we don't need !nm->is_not_entrant() 
>>> either, since
>>> it would return false as you say!?
>>
>> Indeed. All state checks to see if it is even safe to call the state 
>> transition function should be removed, as it should always be safe.
>>
>>> If we should have an early filter it think nm->is_in_use() is 
>>> clearer than:
>>> not not entrant ;) (since the not_installed is normally not seen here)
>>
>> The transitioning functions themselves already have early checks, so 
>> there really is nothing to gain from checking if we should transition 
>> first and then doing it.
>>
>>>>
>>>> For what I propose to work out, we need to change 
>>>> nmethod::make_in_use to use nmethod::try_transition, and 
>>>> AOTCompiledMethod::make_entrant() needs to also return false when 
>>>> encountering a not_entrant nmethod, enforcing monotonicity, instead 
>>>> of asserting about that. AOT methods may turn not_in_use AOT 
>>>> methods to in_use, but not not_entrant to in_use. Once not_entrant, 
>>>> an AOT methods should remain not entrant forever.
>>>
>>> The only time we see methods which are not installed should be 
>>> methods that will
>>> never be deoptimize (except when calling the test method
>>> mark_all_nmethods_for_deoptimization), intrinsic and native.
>>
>> That's not right. It's visible to a bunch of deoptimizations.
>>
>>> And if I remember correctly make_in_use is called in a constructor 
>>> which
>>> requires extra error-handling. Construction would fail if 
>>> try_transition failed.
>>> The assumption about these 'never deopted' methods seem to be just 
>>> that :)
>>
>> That is also not right. We grab the code cache lock, create the 
>> nmethod, verify dependencies, install dependencies, drop the code 
>> cache lock, all under not_installed. It's only after linking the 
>> Method to the code, that we eventually set it to in_use. So it's 
>> visible for longer than you thought. And it's visible to calls, a 
>> small instant before we change the state to in_use(). That's what I 
>> claim isn't right. We don't want to be able to call into these guys.
>>
>>>>
>>>> So basically, these guards are for something that used to be racy 
>>>> and dangerous due to the lack of guards inside of the state 
>>>> transitions, and today that is completely harmless, as the proper 
>>>> guards are in the attempts to change state. I would prefer to 
>>>> remove these guards, as it is confusing to the reader that we are 
>>>> guarding against a problem that can't happen. So I think you can 
>>>> remove the various checks for what state the nmethod is in, the 
>>>> comments describing races, and just keep the checks if it's a 
>>>> method handle intrinsic or native method.
>>>
>>> I'll revisit this. Was a few months since I did this.
>>
>> Okay!
>>
>>>>
>>>> In deoptimize.cpp, the fetch_unroll_info_helper function has moved 
>>>> down, making it difficult to review as shows the code delta as if 
>>>> everything changed. So I can't see what actually changed there. :( 
>>>> Would you mind moving that code back so the webrev shows what 
>>>> changed there?
>>>
>>> I have inserted two new static functions before 
>>> fetch_unroll_info_helper,
>>> since code from fetch_unroll_info_helper are in these functions diff 
>>> do this.
>>> They are static function they are best off before, and putting after 
>>> them I
>>> don't think would help the diff tool + I need fwd decl.
>>> Suggestion?
>>
>> Okay, I will try to work out what the actual diff is manually.
>>
>> Thanks,
>> /Erik
>>
>>> Thanks, Robbin
>>>
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>> On 2019-08-28 11:57, Robbin Ehn wrote:
>>>>> Hi, hotspot-dev was the intended list.
>>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>>> Hi all, please consider,
>>>>>>
>>>>>> To get away from the issues of us revoking in the handshake, but 
>>>>>> before deopt
>>>>>> the locks get re-biased before we hit deopt handler, we instead 
>>>>>> revoke in deopt
>>>>>> handler.
>>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>>>>> revoke after
>>>>>> that but before we start looking at the monitors, with a 
>>>>>> NoSafepointVerifier.
>>>>>>
>>>>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>>>>> merge conflicts
>>>>>> some pieces did not apply:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>>>>
>>>>>> So this is what was reviewed.
>>>>>>
>>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>>
>>>>>> Bug 8224795 fix is here:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>>>
>>>>>>
>>>>>> After this we have the same functionally as the reverted change-set.
>>>>>>
>>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>>>>
>>>>>>
>>>>>> This code was messy adding the deopt revocation in 3 places made 
>>>>>> it worse.
>>>>>> Here is a refactoring of that code. (also removed a dead method 
>>>>>> in biasedlocking):
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>>
>>>>>> And here is full:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>>
>>>>>> Also a full squashed patch file:
>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>>
>>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, 
>>>>>> MacOSX still
>>>>>> running.
>>>>>>
>>>>>> Thanks, Robbin
>>>>>>
>>>>>>


From leo.korinth at oracle.com  Wed Sep 11 07:08:07 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 11 Sep 2019 09:08:07 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <297ffc9c-4960-b6d7-e92c-5c5f2e5426ef@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
 <297ffc9c-4960-b6d7-e92c-5c5f2e5426ef@oracle.com>
Message-ID: <558e1475-ac43-4bc2-120d-3e9f5badd049@oracle.com>


On 10/09/2019 23:44, David Holmes wrote:
> Hi Leo,
> 
> Looks fine.
> 
> Thanks,
> David

Thanks for the review! /Leo

> On 10/09/2019 11:39 pm, Leo Korinth wrote:
>>
>>
>> On 02/09/2019 22:38, Kim Barrett wrote:
>>>> On Sep 2, 2019, at 9:06 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>>
>>>> Hi!
>>>>
>>>> This fixup removes NULL checks before FREE_C_HEAP_ARRAY. This is 
>>>> unnecessary as FREE_C_HEAP_ARRAY does also do this NULL check. This 
>>>> is a follow up to 8227168: Cleanup usage of NEW_C_HEAP_ARRAY.
>>>>
>>>> deallocate_counters() in src/hotspot/os/windows/os_perf_windows.cpp 
>>>> does (in addition to NULL the pointer) also set a counter to zero. 
>>>> Although my change "looks" correct, I tried follow the usage of 
>>>> deallocate_counters(), and could not find a call site. Should I 
>>>> create a bug on this, or am I missing something here?
>>>
>>> Your modification to deallocate_counters looks fine.? I don't think
>>> you are missing anything, I think it's not called.? That does look
>>> like it might be a (pre-existing) bug.? Maybe they are immortal?? But
>>> that isn't obvious from a quick skim.
>>>
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8230398
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~lkorinth/8230398
>>>>
>>>> Testing:
>>>> mach5 tier1-3
>>>>
>>>> Thanks,
>>>> Leo
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>>
>>> [pre-existing]
>>> There are some destructors that are unnecessarily nulling out members
>>> after deleting their values, such as here:
>>>
>>> src/hotspot/share/classfile/classLoader.cpp
>>> ? 387?? FREE_C_HEAP_ARRAY(const char, _name);
>>> ? 388?? _name = NULL;
>>>
>>> src/hotspot/share/gc/g1/sparsePRT.cpp
>>> 106 RSHashTable::~RSHashTable() {
>>>
>>> src/hotspot/share/gc/shared/cardTableRS.cpp
>>> 626 CardTableRS::~CardTableRS() {
>>>
>>> src/hotspot/share/runtime/thread.cpp
>>> 1330 NamedThread::~NamedThread() {
>>>
>>> Your call whether you want to do anything about these with this change.
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>>
>>> Other than that, looks good.? I don't need another webrev if you
>>> decide to remove the above assignments to NULL near code you were
>>> already changing.? A more extensive pass for such should perhaps be a
>>> separate change.
>>>
>> I will remove NULL assignments of fields in destructors and keep them 
>> otherwise.
>>
>> I will also add a comment (// handles NULL pointers) to FreeHeap and 
>> os::free to not only describe behaviour, but also to establish a 
>> contract.
>>
>> Also fixed indentation miss in os_perf_windows.cpp
>>
>> Incremental:
>> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
>>
>> Full:
>> http://cr.openjdk.java.net/~lkorinth/8230398/01
>>
>>
>> running tests...

From leo.korinth at oracle.com  Wed Sep 11 07:08:31 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 11 Sep 2019 09:08:31 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <CB8A97E0-3FB3-4209-A38E-1FEA20383D97@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
 <CB8A97E0-3FB3-4209-A38E-1FEA20383D97@oracle.com>
Message-ID: <3bb73188-2ec2-3c80-1518-1beab92fdfe3@oracle.com>

On 11/09/2019 01:33, Kim Barrett wrote:
>> On Sep 10, 2019, at 9:39 AM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>
>> I will remove NULL assignments of fields in destructors and keep them otherwise.
>>
>> I will also add a comment (// handles NULL pointers) to FreeHeap and os::free to not only describe behaviour, but also to establish a contract.
>>
>> Also fixed indentation miss in os_perf_windows.cpp
>>
>> Incremental:
>> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
>>
>> Full:
>> http://cr.openjdk.java.net/~lkorinth/8230398/01
>>
>>
>> running tests...
> 
> Looks good.
> 

Thanks for the review! /Leo

From serguei.spitsyn at oracle.com  Wed Sep 11 07:22:40 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 11 Sep 2019 00:22:40 -0700
Subject: RFR: 8212117 : Class.forName may return a reference to a loaded
 but not linked Class
In-Reply-To: <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com>
References: <198c6c16-995d-32b1-f41f-c3ffc8a6da7d@oracle.com>
 <6d1691eb-220c-ceaf-1302-be2d285f4968@oracle.com>
 <5751ee27-2e15-ad38-0a6a-cf3ad4298ffc@oracle.com>
Message-ID: <798ab1c2-c099-2b19-e0fa-f2877f52d5cc@oracle.com>

Hi Brent,

The updated webrev looks good to me.
At least, I do not see any issues.

Thanks,
Serguei


On 9/5/19 17:09, Brent Christian wrote:
> Hi, David
>
> On 9/5/19 12:52 AM, David Holmes wrote:
>>
>> Good to see this all come together :)
>
> :)
>
>> So to clarify for others any current caller to 
>> find_class_from_class_loader that passes true for "init" was already 
>> implicitly asking for a linked class (as you must be linked before 
>> you can be initialized). With that in mind I would suggest that in 
>> find_class_from_class_loader you add an assert:
>>
>> ! jclass find_class_from_class_loader(JNIEnv* env, Symbol* name, 
>> jboolean init, jboolean link,
>> ?????????????????????????????????????? Handle loader, Handle 
>> protection_domain,
>> ?????????????????????????????????????? jboolean throwError, TRAPS) {
>> +assert((init && link) || !init, "incorrect use of init/link 
>> arguments");
>>
>> just to ensure the callers understand this.
>
> I'm good with adding an assert to check for coherent arguments.
>
> (Another interpretation is that if 'init' is set, then the 'link' 
> argument is ignored, since linking is implied).
>
>> Aside: in looking at this I've spotted another existing bug. JNI 
>> FindClass is not specified to perform class initialization, but the 
>> implementation passes init=true!
>
> OK, thanks.? I've noted this in JDK-8226540.
>
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java
>>
>> I don't see the need for the new note given it already has
>>
>> * @throws LinkageError if the linkage fails
>
> (Discussed in the CSR)
>
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java
>> ... > Is AccessControlException the only exception, that is not a
>> LinkageError, that might be thrown when linking? I would think a 
>> number of others are possible - in particular IllegalAccessError 
>> might occur during verification. Other than the fact a test obviously 
>> triggered this, it's not clear why ACE should be singled out here. ??
>
> Also discussed in the CSR[1].
>
>> test/hotspot/jtreg/serviceability/jvmti/ClassStatus/ClassStatus.java
>>
>> 45???? // public static void foo(Foo f) { }
>>
>> Unclear why this exists. Also the test refers initially to class Foo 
>> but then uses Foo2 and Foo3. ??
>
> I'm guessing it's just a leftover from an earlier version of the test. 
> I've removed the comment, and updated the test @summary.
>
> Serguei, anything to add?
>
>>> There is also a CSR[2] in need of review.
>>
>> I've added a couple of comments and will add myself as a reviewer 
>> once things are near finalized.
>
> Thanks for taking a look.
>
> Updated webrev at:
> http://cr.openjdk.java.net/~bchristi/8212117/webrev10/
>
> -Brent
>
> 1. 
> https://bugs.openjdk.java.net/browse/JDK-8222071?focusedCommentId=14288303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14288303
>
>>>
>>> The spec for the 2-arg and 3-arg Class.forName() methods states they 
>>> will "locate, load, and link" the class, however the linking part is 
>>> not ensured to happen.
>>>
>>> Although the VM spec allows flexibility WRT when classes are linked, 
>>> this is a corner where the Class.forName() spec is not being upheld. 
>>> While this is not an issue for most usages, 8181144 [3] demonstrates 
>>> how this can be a problem (with the debugging interface, in this case).
>>>
>>> This fix ensures that linking happens during the course of 
>>> Class.forName().? Class.forName() already @throws LinkageError, so 
>>> no spec change is needed there. MethodHandles.Lookup.findClass() 
>>> needs a small spec update, due to calling Class.forName with 
>>> init=false,
>>>
>>> Of course Errors are not required to be caught.? It is therefore 
>>> possible that the new behavior could introduce previously unseen, 
>>> possibly unhandled LinkageErrors.? A new VM flag 
>>> (-XX:+ClassForNameDeferLinking) is introduced to restore the 
>>> previous behavior (to keep such code running until it can be updated).
>>>
>>> This change surfaced a couple new "A JNI error has occurred" 
>>> situations (see 8181033[5]) in the Launcher, by way of
>>> ?? test/jdk/tools/launcher/MainClassCantBeLoadedTest.java
>>> (using the 3-arg Class::forName, detailed in the bug report[4]),
>>> and
>>> ?? test/jdk/tools/launcher/modules/basic/LauncherErrors.java
>>> (using the 2-arg Class::forName).
>>>
>>> The Launcher is updated to maintain non-confusing error messages :).
>>>
>>> The new test included with this fix ensures that 8181144[3] is 
>>> addressed.? Thanks go to Serguei Spitsyn for writing the test.
>>>
>>> Automated corelibs and hotspot tests pass cleanly.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> -- 
>>> 1. https://bugs.openjdk.java.net/browse/JDK-8212117
>>>
>>> 2. https://bugs.openjdk.java.net/browse/JDK-8222071
>>>
>>> 3. https://bugs.openjdk.java.net/browse/JDK-8181144
>>>
>>> 4. 
>>> https://bugs.openjdk.java.net/browse/JDK-8212117?focusedCommentId=14215986&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14215986 
>>>
>>>
>>> 5. https://bugs.openjdk.java.net/browse/JDK-8181033
>>>


From thomas.schatzl at oracle.com  Wed Sep 11 08:39:20 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 11 Sep 2019 10:39:20 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
Message-ID: <edd2fd7e-129a-88dd-8f18-518335a02ceb@oracle.com>

Hi,

On 9/10/19 3:39 PM, Leo Korinth wrote:
> 
[...]
>>
> I will remove NULL assignments of fields in destructors and keep them 
> otherwise.
> 
> I will also add a comment (// handles NULL pointers) to FreeHeap and 
> os::free to not only describe behaviour, but also to establish a contract.
> 
> Also fixed indentation miss in os_perf_windows.cpp
> 
> Incremental:
> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
> 
> Full:
> http://cr.openjdk.java.net/~lkorinth/8230398/01
> 
> 
> running tests...

   still looks good.

Thomas

From leo.korinth at oracle.com  Wed Sep 11 12:12:22 2019
From: leo.korinth at oracle.com (Leo Korinth)
Date: Wed, 11 Sep 2019 14:12:22 +0200
Subject: RFR: 8230398: Remove NULL checks before FREE_C_HEAP_ARRAY
In-Reply-To: <edd2fd7e-129a-88dd-8f18-518335a02ceb@oracle.com>
References: <1891eff3-ff06-9d20-3cee-6a260fcb7b7d@oracle.com>
 <32CFA146-2441-4F1B-8689-976486C1BD5C@oracle.com>
 <dfd58956-09cd-29d9-f831-aa6be8c97888@oracle.com>
 <edd2fd7e-129a-88dd-8f18-518335a02ceb@oracle.com>
Message-ID: <8545a74d-bd6b-5af7-7e48-aece48925fd7@oracle.com>

Thanks for your review!

/Leo

On 11/09/2019 10:39, Thomas Schatzl wrote:
> Hi,
> 
> On 9/10/19 3:39 PM, Leo Korinth wrote:
>>
> [...]
>>>
>> I will remove NULL assignments of fields in destructors and keep them 
>> otherwise.
>>
>> I will also add a comment (// handles NULL pointers) to FreeHeap and 
>> os::free to not only describe behaviour, but also to establish a 
>> contract.
>>
>> Also fixed indentation miss in os_perf_windows.cpp
>>
>> Incremental:
>> http://cr.openjdk.java.net/~lkorinth/8230398/00_01
>>
>> Full:
>> http://cr.openjdk.java.net/~lkorinth/8230398/01
>>
>>
>> running tests...
> 
>  ? still looks good.
> 
> Thomas

From robbin.ehn at oracle.com  Wed Sep 11 12:27:28 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 11 Sep 2019 14:27:28 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <11c23e92-a913-1b1b-70e3-ae973b731ac5@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <f52eaf30-f804-eb0a-7cc9-faf3dadddb0c@oracle.com>
 <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com>
 <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
 <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
 <11c23e92-a913-1b1b-70e3-ae973b731ac5@oracle.com>
Message-ID: <c3786229-e4c8-d154-33bc-7273bb658dd0@oracle.com>

Hi Patricio,

On 2019-09-11 08:07, Patricio Chilano wrote:
> Hi Robbin,
> 
> Thanks for looking into this and for making fetch_unroll_info_helper() more 
> clear to read!
> I looked again at the biased locking part only since I don't really know the 
> rest of code. Those look good to me, just some comments:
> 
> src/hotspot/share/runtime/deoptimization.cpp:
> 1) What was the problem of calling revoke_from_deopt_handler() before 
> eliminate_allocations()?

JRT_BLOCK can safepoint, which would leads us back to the original problem.

> 2) If COMPILER2_OR_JVMCI is 0, shouldn't we still call revoke_from_deopt_handler()?

Yes, thanks, fixed!

> 
> src/hotspot/share/runtime/biasedLocking.cpp:
> L737: markWord prototype_header = k->prototype_header();
> Although that will probably get optimized away in product code, I would just 
> place that load inside the assert.

Fixed!

> 
> src/hotspot/share/runtime/biasedLocking.xpp:
> Maybe s/revoke_own_locks()/revoke_own_lock() ?
> 

Fixed!

> Regarding InterpreterRuntime::frequency_counter_overflow_inner() having possibly 
> the same bug, not sure I see the trace for that.

After your rebaised patch, things have changed a bit, so it might be good now. 
(revoke do not safepoint)

I'll post a v3 to RFR mail.

Thanks, Robbin

> 
> Thanks!
> Patricio
> 
> On 9/9/19 9:45 AM, Robbin Ehn wrote:
>> Hi all,
>>
>> Me and Erik had some offline discussions, which ended up in this incremental 
>> change:
>> http://cr.openjdk.java.net/~rehn/8226705/v2/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v2/full/webrev/
>>
>> The problem is a nmethods state must never go backwards.
>> When the methods code is set to the compiled code it can be made not_entrant.
>> (it can be set to not_entrant before not having Compiled_lock)
>> When unlinking the methods code must point to the nmethod.
>>
>> If we set code before changing state, it can go backwards.
>> If we set state before setting code, we can't unlink it.
>>
>> This solution uses the new CompiledMethod_lock to synchronize code and state 
>> changes. (unloaded don't need the lock since it require a safepoint to happen)
>>
>> But this resulted in a circular lock issue with OsrList_lock.
>> Therefore OsrList_lock is removed, instead we use CompiledMethod_lock.
>>
>> After this patch it should be possible to remove Compile_lock from some paths. 
>> (Note that JVMCI is missing Compile_lock from several pathes, but fewer with 
>> this changeset)
>>
>> Also InterpreterRuntime::frequency_counter_overflow_inner seem to have the 
>> same bug as the reason for this redo: BiasedLocking::revoke(objects_to_revoke, 
>> thread);
>> The objects could have been rebaised by the time we return from it.
>> I think we should call the new 
>> BiasedLocking::revoke_own_locks(objects_to_revoke->at(i), thread); here also.
>>
>> Passes t1-5 twice and KS 60 min.
>>
>> @Erik I stayed with current is_in_use (not_installed + in_use), there were to 
>> many places and many of them needed an equivalent method if is_in_use was to 
>> be changed (to only in_use). I didn't see any issue with using the current 
>> definition.
>>
>> Thanks, Robbin
>>
>> On 8/29/19 4:35 PM, Erik ?sterlund wrote:
>>> Hi Robbin,
>>>
>>> On 2019-08-29 14:25, Robbin Ehn wrote:
>>>> Hi Erik, thanks for having a look.
>>>>
>>>> Just some short answers and questions.
>>>>
>>>> On 8/29/19 12:01 PM, Erik ?sterlund wrote:
>>>>> Hi Robbin,
>>>>>
>>>>> Glad to see this work making it back again. Last time this patch was 
>>>>> proposed, there were no guards against non-monotonic nmethod state 
>>>>> transitions. Today there are (since 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, if you 
>>>>> call make_not_entrant() on an nmethod that has racingly become zombie, it 
>>>>> is today impossible to resurrect that nmethod. Instead, make_not_entrant() 
>>>>> will return false.
>>>>
>>>> Great, I'll have a look.
>>>>
>>>>>
>>>>> In particular, I think that is what the following code in the patch is 
>>>>> guarding against (in codeCache.cpp):
>>>>>
>>>>> 1150 // Mark methods for deopt (if safe or possible).
>>>>> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() {
>>>>> 1152?? MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>>>>> 1153?? CompiledMethodIterator 
>>>>> iter(CompiledMethodIterator::only_alive_and_not_unloading);
>>>>> 1154?? while(iter.next()) {
>>>>> 1155???? CompiledMethod* nm = iter.method();
>>>>> 1156???? if (!nm->method()->is_method_handle_intrinsic() &&
>>>>> 1157???????? !nm->is_not_installed() &&
>>>>> 1158???????? nm->is_in_use() &&
>>>>> 1159???????? !nm->is_native_method()) {
>>>>> 1160?????? // Intrinsics and native methods are never deopted. A method 
>>>>> that is
>>>>> 1161?????? // not installed yet or is not in use is not safe to deopt; the
>>>>> 1162?????? // is_in_use() check covers the not_entrant and not zombie cases.
>>>>> 1163?????? // Note: A not_entrant method can become a zombie at anytime if 
>>>>> it was
>>>>> 1164?????? // made not_entrant before the previous safepoint/handshake.
>>>>> 1165?????? nm->mark_for_deoptimization();
>>>>> 1166???? }
>>>>> 1167?? }
>>>>> 1168 }
>>>>>
>>>>> In fact, this code is also guarding against is_not_installed nmethods 
>>>>> (which was introduced as a new function). If we find that an nmethod is bad 
>>>>> and say it needs deoptimization, and that nmethod is just about to get 
>>>>> installed, it seems to me that skipping that nmethod and not making it not 
>>>>> entrant is really dangerous and will eventually lead to a crash. Because in 
>>>>> ciEnv.cpp we set_code to the about to be installed nmethod, and it will get 
>>>>> called without anything stopping the invalid code from being executed by 
>>>>> mutators, and it was being invalidated for a reason. So basically we really 
>>>>> do have to make these not entrant, or we will blow up.
>>>>>
>>>>> I guess the reason you needed this check is because make_in_use() doesn't 
>>>>> check what the current state is, causing monotonicity problems, making a 
>>>>> potentially already not entrant nmethod become in_use, eventually blowing 
>>>>> up asserts and probably the VM. Regrettably, make_in_use() still does that, 
>>>>> because I had no need for changing it to use nmethod::try_transition in 
>>>>> 8224674, nobody previously could find these nmethods. In retrospect, not 
>>>>> changing that was a bit silly. So if we just change make_in_use() to use 
>>>>> nmethod::try_transition instead, then you can remove the !is_not_installed 
>>>>> check... which I argue we have to do. The reason we never ran in to this 
>>>>> before is because we made the nmethods not entrant in a safepoint, and 
>>>>> between making an nmethod and making it in_use, there is no safepoint 
>>>>> check, so they were never observed in this state.
>>>>>
>>>>
>>>> Yes, thread A is creating a new method X, it have state not installed.
>>>> If we make method X not entrant, Thread A will flip it back to in_use, which 
>>>> bad
>>>> and we crash. mark_all_nmethods_for_deoptimization is a test method used in the
>>>> new jtreg test, which is the only use (I see dtrace have some hack to use 
>>>> it, it
>>>> can crash the vm).
>>>
>>> Exactly. However, what you are missing here is that this does not happen only 
>>> for the whitebox test, now that we do normal deopt with handshakes.
>>>
>>> Consider the following race.
>>>
>>> A compiler thread compiles a new nmethod. In this nmethod, it's assumed that 
>>> a certain invoke_virtual callsite is completely monomorphic, and the compiler 
>>> chooses to implement the callsite with a direct call, which is only valid 
>>> given its monomorphism. The compilation finishes, and at the very end of the 
>>> process, the code cache lock is grabbed, under which we allocate the new 
>>> nmethod, verify the assumptions made (which still hold), inject entries in 
>>> DependencyContexts so that if these assumptions change, we will deopt, and 
>>> then unlock the code cache lock. The nmethod is now still in the state 
>>> not_installed.
>>>
>>> What can happen now is that another thread loads a class that makes the 
>>> callsite potentially megamorphic. Deopt is triggered, walking the dependency 
>>> contexts under the CodeCache_lock, marking things that are now bad. In this 
>>> list we will find the newly compiled nmethod that has not been made in_use 
>>> yet. It is marked for deoptimization. Then the 
>>> Deoptimization::deoptimize_all_marked() function is called to make sure that 
>>> we 1) make all the marked nmethods not_entrant, and 2) arm the bad activation 
>>> records in the stack. Now the first step of the two grabs the code cache 
>>> lock, and walks the code cache. It finds our about to be installed nmethod, 
>>> and shoots make_not_entrant() at it, racing with the compiler thread calling 
>>> make_in_use() on it.
>>>
>>> This is why I advocate an approach where we simply make it safe to call 
>>> make_in_use() racing with make_not_entrant(), instead of trying to chase down 
>>> all possible scenarios in which this can happen. I can imagine a number of 
>>> others, now that deoptimization is being done with handshakes.
>>>
>>>>> ... and similarly here:
>>>>>
>>>>> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) {
>>>>> 1193?????? // only_alive_and_not_unloading() can return not_entrant nmethods.
>>>>> 1194?????? // A not_entrant method can become a zombie at anytime if it was
>>>>> 1195?????? // made not_entrant before the previous safepoint/handshake. The
>>>>> 1196?????? // is_in_use() check covers the not_entrant and not zombie cases
>>>>> 1197?????? // that have become true after the method was marked for deopt.
>>>>> 1198?????? nm->make_not_entrant();
>>>>> 1199???? }
>>>>>
>>>>> ... we now don't need the guard against is_in_use() here.
>>>>
>>>> Here we don't need that, but we don't need !nm->is_not_entrant() either, since
>>>> it would return false as you say!?
>>>
>>> Indeed. All state checks to see if it is even safe to call the state 
>>> transition function should be removed, as it should always be safe.
>>>
>>>> If we should have an early filter it think nm->is_in_use() is clearer than:
>>>> not not entrant ;) (since the not_installed is normally not seen here)
>>>
>>> The transitioning functions themselves already have early checks, so there 
>>> really is nothing to gain from checking if we should transition first and 
>>> then doing it.
>>>
>>>>>
>>>>> For what I propose to work out, we need to change nmethod::make_in_use to 
>>>>> use nmethod::try_transition, and AOTCompiledMethod::make_entrant() needs to 
>>>>> also return false when encountering a not_entrant nmethod, enforcing 
>>>>> monotonicity, instead of asserting about that. AOT methods may turn 
>>>>> not_in_use AOT methods to in_use, but not not_entrant to in_use. Once 
>>>>> not_entrant, an AOT methods should remain not entrant forever.
>>>>
>>>> The only time we see methods which are not installed should be methods that 
>>>> will
>>>> never be deoptimize (except when calling the test method
>>>> mark_all_nmethods_for_deoptimization), intrinsic and native.
>>>
>>> That's not right. It's visible to a bunch of deoptimizations.
>>>
>>>> And if I remember correctly make_in_use is called in a constructor which
>>>> requires extra error-handling. Construction would fail if try_transition 
>>>> failed.
>>>> The assumption about these 'never deopted' methods seem to be just that :)
>>>
>>> That is also not right. We grab the code cache lock, create the nmethod, 
>>> verify dependencies, install dependencies, drop the code cache lock, all 
>>> under not_installed. It's only after linking the Method to the code, that we 
>>> eventually set it to in_use. So it's visible for longer than you thought. And 
>>> it's visible to calls, a small instant before we change the state to 
>>> in_use(). That's what I claim isn't right. We don't want to be able to call 
>>> into these guys.
>>>
>>>>>
>>>>> So basically, these guards are for something that used to be racy and 
>>>>> dangerous due to the lack of guards inside of the state transitions, and 
>>>>> today that is completely harmless, as the proper guards are in the attempts 
>>>>> to change state. I would prefer to remove these guards, as it is confusing 
>>>>> to the reader that we are guarding against a problem that can't happen. So 
>>>>> I think you can remove the various checks for what state the nmethod is in, 
>>>>> the comments describing races, and just keep the checks if it's a method 
>>>>> handle intrinsic or native method.
>>>>
>>>> I'll revisit this. Was a few months since I did this.
>>>
>>> Okay!
>>>
>>>>>
>>>>> In deoptimize.cpp, the fetch_unroll_info_helper function has moved down, 
>>>>> making it difficult to review as shows the code delta as if everything 
>>>>> changed. So I can't see what actually changed there. :( Would you mind 
>>>>> moving that code back so the webrev shows what changed there?
>>>>
>>>> I have inserted two new static functions before fetch_unroll_info_helper,
>>>> since code from fetch_unroll_info_helper are in these functions diff do this.
>>>> They are static function they are best off before, and putting after them I
>>>> don't think would help the diff tool + I need fwd decl.
>>>> Suggestion?
>>>
>>> Okay, I will try to work out what the actual diff is manually.
>>>
>>> Thanks,
>>> /Erik
>>>
>>>> Thanks, Robbin
>>>>
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>> On 2019-08-28 11:57, Robbin Ehn wrote:
>>>>>> Hi, hotspot-dev was the intended list.
>>>>>>
>>>>>> Thanks, Robbin
>>>>>>
>>>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>>>> Hi all, please consider,
>>>>>>>
>>>>>>> To get away from the issues of us revoking in the handshake, but before 
>>>>>>> deopt
>>>>>>> the locks get re-biased before we hit deopt handler, we instead revoke in 
>>>>>>> deopt
>>>>>>> handler.
>>>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke 
>>>>>>> after
>>>>>>> that but before we start looking at the monitors, with a 
>>>>>>> NoSafepointVerifier.
>>>>>>>
>>>>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge 
>>>>>>> conflicts
>>>>>>> some pieces did not apply:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>>>>> So this is what was reviewed.
>>>>>>>
>>>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>>>
>>>>>>> Bug 8224795 fix is here:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>>>>
>>>>>>>
>>>>>>> After this we have the same functionally as the reverted change-set.
>>>>>>>
>>>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>>>>
>>>>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>>>>> Here is a refactoring of that code. (also removed a dead method in 
>>>>>>> biasedlocking):
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>>>
>>>>>>> And here is full:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>>>
>>>>>>> Also a full squashed patch file:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>>>
>>>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>>>>> running.
>>>>>>>
>>>>>>> Thanks, Robbin
>>>>>>>
>>>>>>>
> 

From stefan.reich.maker.of.eye at googlemail.com  Wed Sep 11 12:30:15 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Wed, 11 Sep 2019 14:30:15 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
 <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>
Message-ID: <CAC2-jLHT_iQs-XgkyjvrvB-Bc9eCu61nNW-X4KQYQG5pCz-aTA@mail.gmail.com>

I'm thinking about becoming a JCP member to turn this idea (merging this$x
fields) into a JSR.

The JCP paperwork seems scary though, and I don't speak their programming
language (legalese) enough to really get what is demanded...
https://jcp.org/aboutJava/communityprocess/JSPA2.pdf

It seems I could become a JCP member as an individual without having to pay
a fee. Not sure what all the "IP" fuss is about. "Are you willing and able
to sign the JSPA and license IP"? License MY IP to Oracle? Or the other way
around? Who can help me out there?

Greetings

On Tue, 10 Sep 2019 at 01:30, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Oh, I didn't know about those JDK 11 changes. That may in fact break the
> idea of merging the references. I'm sure it can still be done, but might
> require a spec change. And who's gonna pay for that?
>
> :-D
>
> Thanks
>
> On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 10/09/2019 9:09 am, Stefan Reich wrote:
>> >     But you're not talking about bytecode here you're talking about
>> inside
>> >     the VM. If there is an invokespecial on this$1 of type A then the
>> >     constant pool lookup of its type will be A and we will resolve the
>> call
>> >     based on A's methods. If it were of type B then the resolution
>> process
>> >     would be different. There's nowhere to "insert a cast" here.
>> >
>> >
>> > Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a
>> > case for this.
>> >
>> > invokespecial invokes private instance methods, superclass methods or
>> > constructors. Superclass methods don't apply, neither do constructors.
>> > And calls to private methods happen through bridges (just verified this
>> > for myself again :):
>> >
>> >        13: aload_0
>> >        14: getfield      #1                  // Field this$0:Lbla;
>> >        17: invokestatic  #4                  // Method
>> > bla.access$000:(Lbla;)V
>> >
>> > So what remains?
>>
>> This changed in JDK 11 with the addition of nestmates. Now inner classes
>> have direct private access, no bridges needed, and we use invokespecial
>> or invokevirtual as appropriate. For private methods invokevirtual is
>> mainly used now, but of course we don't do virtual dispatch - there are
>> special rules for private method resolution and selection.
>>
>> class A {
>>    void m() {}
>>    class InnerA {
>>      void callM() { m(); }
>>    }
>> }
>>
>>   void callM();
>>      descriptor: ()V
>>      flags: (0x0000)
>>      Code:
>>        stack=1, locals=1, args_size=1
>>           0: aload_0
>>           1: getfield      #1                  // Field this$0:LA;
>>           4: invokevirtual #13                 // Method A.m:()V
>>           7: return
>>        LineNumberTable:
>>          line 4: 0
>>
>> >     BTW what introspection tool did you use to show this?
>> >
>> > My own tools ("JavaX")... here's the example program:
>> > http://code.botcompany.de/1025166
>>
>> Thanks for the pointer.
>>
>> Cheers,
>> David
>>
>> > Many greetings :)
>>
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Wed Sep 11 12:42:42 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2019 22:42:42 +1000
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLHT_iQs-XgkyjvrvB-Bc9eCu61nNW-X4KQYQG5pCz-aTA@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
 <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>
 <CAC2-jLHT_iQs-XgkyjvrvB-Bc9eCu61nNW-X4KQYQG5pCz-aTA@mail.gmail.com>
Message-ID: <2ca33b0e-bb10-c298-521c-f1d7004e7c73@oracle.com>

On 11/09/2019 10:30 pm, Stefan Reich wrote:
> I'm thinking about becoming a JCP member to turn this idea (merging 
> this$x fields) into a JSR.

This doesn't require a JSR, nor do you need to become a JCP member.

This is just an enhancement request for the hotspot implementation 
(assuming it is actually valid, viable and worthwhile).

To work on this all you need to do is become an OpenJDK contributor:

http://openjdk.java.net/contribute/

If the issue is large enough then it may warrant a Java Enhancement 
Proposal (JEP):

https://openjdk.java.net/jeps/1

David
-----

> The JCP paperwork seems scary though, and I don't speak their 
> programming language (legalese) enough to really get what is demanded... 
> https://jcp.org/aboutJava/communityprocess/JSPA2.pdf
> 
> It seems I could become a JCP member as an individual without having to 
> pay a fee. Not sure what all the "IP" fuss is about. "Are you willing 
> and able to sign the JSPA and license IP"? License MY IP to Oracle? Or 
> the other way around? Who can help me out there?
> 
> Greetings
> 
> On Tue, 10 Sep 2019 at 01:30, Stefan Reich 
> <stefan.reich.maker.of.eye at googlemail.com 
> <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
> 
>     Oh, I didn't know about those JDK 11 changes. That may in fact break
>     the idea of merging the references. I'm sure it can still be done,
>     but might require a spec change. And who's gonna pay for that?
> 
>     :-D
> 
>     Thanks
> 
>     On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>> wrote:
> 
>         On 10/09/2019 9:09 am, Stefan Reich wrote:
>          >? ? ?But you're not talking about bytecode here you're talking
>         about inside
>          >? ? ?the VM. If there is an invokespecial on this$1 of type A
>         then the
>          >? ? ?constant pool lookup of its type will be A and we will
>         resolve the call
>          >? ? ?based on A's methods. If it were of type B then the
>         resolution process
>          >? ? ?would be different. There's nowhere to "insert a cast" here.
>          >
>          >
>          > Can invokespecials on this$0/this$1 happen? I'm struggling to
>         imagine a
>          > case for this.
>          >
>          > invokespecial invokes private instance methods, superclass
>         methods or
>          > constructors. Superclass methods don't apply, neither do
>         constructors.
>          > And calls to private methods happen through bridges (just
>         verified this
>          > for myself again :):
>          >
>          >? ? ? ? 13: aload_0
>          >? ? ? ? 14: getfield ? ? ?#1 ? ? ? ? ? ? ? ? ?// Field
>         this$0:Lbla;
>          >? ? ? ? 17: invokestatic ?#4 ? ? ? ? ? ? ? ? ?// Method
>          > bla.access$000:(Lbla;)V
>          >
>          > So what remains?
> 
>         This changed in JDK 11 with the addition of nestmates. Now inner
>         classes
>         have direct private access, no bridges needed, and we use
>         invokespecial
>         or invokevirtual as appropriate. For private methods
>         invokevirtual is
>         mainly used now, but of course we don't do virtual dispatch -
>         there are
>         special rules for private method resolution and selection.
> 
>         class A {
>          ? ?void m() {}
>          ? ?class InnerA {
>          ? ? ?void callM() { m(); }
>          ? ?}
>         }
> 
>          ? void callM();
>          ? ? ?descriptor: ()V
>          ? ? ?flags: (0x0000)
>          ? ? ?Code:
>          ? ? ? ?stack=1, locals=1, args_size=1
>          ? ? ? ? ? 0: aload_0
>          ? ? ? ? ? 1: getfield? ? ? #1? ? ? ? ? ? ? ? ? // Field this$0:LA;
>          ? ? ? ? ? 4: invokevirtual #13? ? ? ? ? ? ? ? ?// Method A.m:()V
>          ? ? ? ? ? 7: return
>          ? ? ? ?LineNumberTable:
>          ? ? ? ? ?line 4: 0
> 
>          >? ? ?BTW what introspection tool did you use to show this?
>          >
>          > My own tools ("JavaX")... here's the example program:
>          > http://code.botcompany.de/1025166
> 
>         Thanks for the pointer.
> 
>         Cheers,
>         David
> 
>          > Many greetings :)
> 
> 
> 
>     -- 
>     Stefan Reich
>     BotCompany.de // Java-based operating systems
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Wed Sep 11 12:43:43 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Wed, 11 Sep 2019 14:43:43 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <2ca33b0e-bb10-c298-521c-f1d7004e7c73@oracle.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
 <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>
 <CAC2-jLHT_iQs-XgkyjvrvB-Bc9eCu61nNW-X4KQYQG5pCz-aTA@mail.gmail.com>
 <2ca33b0e-bb10-c298-521c-f1d7004e7c73@oracle.com>
Message-ID: <CAC2-jLF81dHcqhHjM6hKn5qyk5ge2rWF79-jfqQb7tnK4LvnSg@mail.gmail.com>

Oh, because it doesn't affect the Java source level, right? Got it. Thanks

On Wed, 11 Sep 2019 at 14:42, David Holmes <david.holmes at oracle.com> wrote:

> On 11/09/2019 10:30 pm, Stefan Reich wrote:
> > I'm thinking about becoming a JCP member to turn this idea (merging
> > this$x fields) into a JSR.
>
> This doesn't require a JSR, nor do you need to become a JCP member.
>
> This is just an enhancement request for the hotspot implementation
> (assuming it is actually valid, viable and worthwhile).
>
> To work on this all you need to do is become an OpenJDK contributor:
>
> http://openjdk.java.net/contribute/
>
> If the issue is large enough then it may warrant a Java Enhancement
> Proposal (JEP):
>
> https://openjdk.java.net/jeps/1
>
> David
> -----
>
> > The JCP paperwork seems scary though, and I don't speak their
> > programming language (legalese) enough to really get what is demanded...
> > https://jcp.org/aboutJava/communityprocess/JSPA2.pdf
> >
> > It seems I could become a JCP member as an individual without having to
> > pay a fee. Not sure what all the "IP" fuss is about. "Are you willing
> > and able to sign the JSPA and license IP"? License MY IP to Oracle? Or
> > the other way around? Who can help me out there?
> >
> > Greetings
> >
> > On Tue, 10 Sep 2019 at 01:30, Stefan Reich
> > <stefan.reich.maker.of.eye at googlemail.com
> > <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
> >
> >     Oh, I didn't know about those JDK 11 changes. That may in fact break
> >     the idea of merging the references. I'm sure it can still be done,
> >     but might require a spec change. And who's gonna pay for that?
> >
> >     :-D
> >
> >     Thanks
> >
> >     On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com
> >     <mailto:david.holmes at oracle.com>> wrote:
> >
> >         On 10/09/2019 9:09 am, Stefan Reich wrote:
> >          >     But you're not talking about bytecode here you're talking
> >         about inside
> >          >     the VM. If there is an invokespecial on this$1 of type A
> >         then the
> >          >     constant pool lookup of its type will be A and we will
> >         resolve the call
> >          >     based on A's methods. If it were of type B then the
> >         resolution process
> >          >     would be different. There's nowhere to "insert a cast"
> here.
> >          >
> >          >
> >          > Can invokespecials on this$0/this$1 happen? I'm struggling to
> >         imagine a
> >          > case for this.
> >          >
> >          > invokespecial invokes private instance methods, superclass
> >         methods or
> >          > constructors. Superclass methods don't apply, neither do
> >         constructors.
> >          > And calls to private methods happen through bridges (just
> >         verified this
> >          > for myself again :):
> >          >
> >          >        13: aload_0
> >          >        14: getfield      #1                  // Field
> >         this$0:Lbla;
> >          >        17: invokestatic  #4                  // Method
> >          > bla.access$000:(Lbla;)V
> >          >
> >          > So what remains?
> >
> >         This changed in JDK 11 with the addition of nestmates. Now inner
> >         classes
> >         have direct private access, no bridges needed, and we use
> >         invokespecial
> >         or invokevirtual as appropriate. For private methods
> >         invokevirtual is
> >         mainly used now, but of course we don't do virtual dispatch -
> >         there are
> >         special rules for private method resolution and selection.
> >
> >         class A {
> >             void m() {}
> >             class InnerA {
> >               void callM() { m(); }
> >             }
> >         }
> >
> >            void callM();
> >               descriptor: ()V
> >               flags: (0x0000)
> >               Code:
> >                 stack=1, locals=1, args_size=1
> >                    0: aload_0
> >                    1: getfield      #1                  // Field
> this$0:LA;
> >                    4: invokevirtual #13                 // Method A.m:()V
> >                    7: return
> >                 LineNumberTable:
> >                   line 4: 0
> >
> >          >     BTW what introspection tool did you use to show this?
> >          >
> >          > My own tools ("JavaX")... here's the example program:
> >          > http://code.botcompany.de/1025166
> >
> >         Thanks for the pointer.
> >
> >         Cheers,
> >         David
> >
> >          > Many greetings :)
> >
> >
> >
> >     --
> >     Stefan Reich
> >     BotCompany.de // Java-based operating systems
> >
> >
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Wed Sep 11 12:48:21 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Sep 2019 22:48:21 +1000
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <CAC2-jLF81dHcqhHjM6hKn5qyk5ge2rWF79-jfqQb7tnK4LvnSg@mail.gmail.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
 <CAC2-jLGeN2ihLDXjxWQ2wAyXsezv-0C-9KPLVvkOigpSte=RxQ@mail.gmail.com>
 <CAC2-jLHT_iQs-XgkyjvrvB-Bc9eCu61nNW-X4KQYQG5pCz-aTA@mail.gmail.com>
 <2ca33b0e-bb10-c298-521c-f1d7004e7c73@oracle.com>
 <CAC2-jLF81dHcqhHjM6hKn5qyk5ge2rWF79-jfqQb7tnK4LvnSg@mail.gmail.com>
Message-ID: <20c92572-8c30-db9c-b1e8-b7ff9de1e622@oracle.com>

On 11/09/2019 10:43 pm, Stefan Reich wrote:
> Oh, because it doesn't affect the Java source level, right? Got it. Thanks

No, because it's not related to defining a specific platform 
specification - which is what JSRs are for. These days everything in 
OpenJDK is developed within the community, with larger projects handled 
within a JEP. Then ultimately there is, I believe, a JSR (or JSR update) 
for each actual release.

David

> On Wed, 11 Sep 2019 at 14:42, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     On 11/09/2019 10:30 pm, Stefan Reich wrote:
>      > I'm thinking about becoming a JCP member to turn this idea (merging
>      > this$x fields) into a JSR.
> 
>     This doesn't require a JSR, nor do you need to become a JCP member.
> 
>     This is just an enhancement request for the hotspot implementation
>     (assuming it is actually valid, viable and worthwhile).
> 
>     To work on this all you need to do is become an OpenJDK contributor:
> 
>     http://openjdk.java.net/contribute/
> 
>     If the issue is large enough then it may warrant a Java Enhancement
>     Proposal (JEP):
> 
>     https://openjdk.java.net/jeps/1
> 
>     David
>     -----
> 
>      > The JCP paperwork seems scary though, and I don't speak their
>      > programming language (legalese) enough to really get what is
>     demanded...
>      > https://jcp.org/aboutJava/communityprocess/JSPA2.pdf
>      >
>      > It seems I could become a JCP member as an individual without
>     having to
>      > pay a fee. Not sure what all the "IP" fuss is about. "Are you
>     willing
>      > and able to sign the JSPA and license IP"? License MY IP to
>     Oracle? Or
>      > the other way around? Who can help me out there?
>      >
>      > Greetings
>      >
>      > On Tue, 10 Sep 2019 at 01:30, Stefan Reich
>      > <stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>
>      > <mailto:stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>>> wrote:
>      >
>      >? ? ?Oh, I didn't know about those JDK 11 changes. That may in
>     fact break
>      >? ? ?the idea of merging the references. I'm sure it can still be
>     done,
>      >? ? ?but might require a spec change. And who's gonna pay for that?
>      >
>      >? ? ?:-D
>      >
>      >? ? ?Thanks
>      >
>      >? ? ?On Tue, 10 Sep 2019 at 01:17, 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:
>      >
>      >? ? ? ? ?On 10/09/2019 9:09 am, Stefan Reich wrote:
>      >? ? ? ? ? >? ? ?But you're not talking about bytecode here you're
>     talking
>      >? ? ? ? ?about inside
>      >? ? ? ? ? >? ? ?the VM. If there is an invokespecial on this$1 of
>     type A
>      >? ? ? ? ?then the
>      >? ? ? ? ? >? ? ?constant pool lookup of its type will be A and we will
>      >? ? ? ? ?resolve the call
>      >? ? ? ? ? >? ? ?based on A's methods. If it were of type B then the
>      >? ? ? ? ?resolution process
>      >? ? ? ? ? >? ? ?would be different. There's nowhere to "insert a
>     cast" here.
>      >? ? ? ? ? >
>      >? ? ? ? ? >
>      >? ? ? ? ? > Can invokespecials on this$0/this$1 happen? I'm
>     struggling to
>      >? ? ? ? ?imagine a
>      >? ? ? ? ? > case for this.
>      >? ? ? ? ? >
>      >? ? ? ? ? > invokespecial invokes private instance methods, superclass
>      >? ? ? ? ?methods or
>      >? ? ? ? ? > constructors. Superclass methods don't apply, neither do
>      >? ? ? ? ?constructors.
>      >? ? ? ? ? > And calls to private methods happen through bridges (just
>      >? ? ? ? ?verified this
>      >? ? ? ? ? > for myself again :):
>      >? ? ? ? ? >
>      >? ? ? ? ? >? ? ? ? 13: aload_0
>      >? ? ? ? ? >? ? ? ? 14: getfield ? ? ?#1 ? ? ? ? ? ? ? ? ?// Field
>      >? ? ? ? ?this$0:Lbla;
>      >? ? ? ? ? >? ? ? ? 17: invokestatic ?#4 ? ? ? ? ? ? ? ? ?// Method
>      >? ? ? ? ? > bla.access$000:(Lbla;)V
>      >? ? ? ? ? >
>      >? ? ? ? ? > So what remains?
>      >
>      >? ? ? ? ?This changed in JDK 11 with the addition of nestmates.
>     Now inner
>      >? ? ? ? ?classes
>      >? ? ? ? ?have direct private access, no bridges needed, and we use
>      >? ? ? ? ?invokespecial
>      >? ? ? ? ?or invokevirtual as appropriate. For private methods
>      >? ? ? ? ?invokevirtual is
>      >? ? ? ? ?mainly used now, but of course we don't do virtual dispatch -
>      >? ? ? ? ?there are
>      >? ? ? ? ?special rules for private method resolution and selection.
>      >
>      >? ? ? ? ?class A {
>      >? ? ? ? ? ? ?void m() {}
>      >? ? ? ? ? ? ?class InnerA {
>      >? ? ? ? ? ? ? ?void callM() { m(); }
>      >? ? ? ? ? ? ?}
>      >? ? ? ? ?}
>      >
>      >? ? ? ? ? ? void callM();
>      >? ? ? ? ? ? ? ?descriptor: ()V
>      >? ? ? ? ? ? ? ?flags: (0x0000)
>      >? ? ? ? ? ? ? ?Code:
>      >? ? ? ? ? ? ? ? ?stack=1, locals=1, args_size=1
>      >? ? ? ? ? ? ? ? ? ? 0: aload_0
>      >? ? ? ? ? ? ? ? ? ? 1: getfield? ? ? #1? ? ? ? ? ? ? ? ? // Field
>     this$0:LA;
>      >? ? ? ? ? ? ? ? ? ? 4: invokevirtual #13? ? ? ? ? ? ? ? ?// Method
>     A.m:()V
>      >? ? ? ? ? ? ? ? ? ? 7: return
>      >? ? ? ? ? ? ? ? ?LineNumberTable:
>      >? ? ? ? ? ? ? ? ? ?line 4: 0
>      >
>      >? ? ? ? ? >? ? ?BTW what introspection tool did you use to show this?
>      >? ? ? ? ? >
>      >? ? ? ? ? > My own tools ("JavaX")... here's the example program:
>      >? ? ? ? ? > http://code.botcompany.de/1025166
>      >
>      >? ? ? ? ?Thanks for the pointer.
>      >
>      >? ? ? ? ?Cheers,
>      >? ? ? ? ?David
>      >
>      >? ? ? ? ? > Many greetings :)
>      >
>      >
>      >
>      >? ? ?--
>      >? ? ?Stefan Reich
>      >? ? ?BotCompany.de // Java-based operating systems
>      >
>      >
>      >
>      > --
>      > Stefan Reich
>      > BotCompany.de // Java-based operating systems
> 
> 
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems

From christoph.langer at sap.com  Wed Sep 11 13:25:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Sep 2019 13:25:46 +0000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
Message-ID: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please review this cleanup in test.lib.

One part is the removal/cleanup of @SuppressWarnings annotations. Some are unnecessary and in Utils.java an unchecked warning can be quiesced.

Furthermore, when analyzing some test outputs lately, I got annoyed by stack traces like the following when using jdk.test.lib.process.StreamPumper. I think they are of no particular value and could be suppressed.

java.io.IOException: Stream closed
at java.base/java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:169)
at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:335)
at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:285)
at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:109)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.lang.Thread.run(Thread.java:830)

Bug: https://bugs.openjdk.java.net/browse/JDK-8230854
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8230854.0/

Thanks
Christoph


From thomas.stuefe at gmail.com  Wed Sep 11 13:41:55 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 11 Sep 2019 15:41:55 +0200
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUzcVieKC2d7gE5F+Eqz2iD=azCJ0eRA_o6e3ODc22BEhQ@mail.gmail.com>

Looks good, Christoph.

..Thomas

On Wed, Sep 11, 2019 at 3:26 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
> please review this cleanup in test.lib.
>
> One part is the removal/cleanup of @SuppressWarnings annotations. Some are
> unnecessary and in Utils.java an unchecked warning can be quiesced.
>
> Furthermore, when analyzing some test outputs lately, I got annoyed by
> stack traces like the following when using
> jdk.test.lib.process.StreamPumper. I think they are of no particular value
> and could be suppressed.
>
> java.io.IOException: Stream closed
> at java.base/java.io
> .BufferedInputStream.getBufIfOpen(BufferedInputStream.java:169)
> at java.base/java.io
> .BufferedInputStream.read(BufferedInputStream.java:335)
> at java.base/java.io
> .BufferedInputStream.fill(BufferedInputStream.java:245)
> at java.base/java.io
> .BufferedInputStream.read1(BufferedInputStream.java:285)
> at java.base/java.io
> .BufferedInputStream.read(BufferedInputStream.java:344)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
> at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:109)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:830)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230854
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8230854.0/
>
> Thanks
> Christoph
>
>

From alexandr.miloslavskiy at gmail.com  Wed Sep 11 14:09:22 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Wed, 11 Sep 2019 16:09:22 +0200
Subject: How to native debug Java on macOS?
In-Reply-To: <56772077-fc61-9f57-4ffa-19c27e0d7724@oracle.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <4C461FF8-470C-406A-9F95-2D769232644F@gmail.com>
 <8b4ef3dc-86b5-9f23-1417-19776a969c84@gmail.com>
 <56772077-fc61-9f57-4ffa-19c27e0d7724@oracle.com>
Message-ID: <8f5ce52c-e343-94d8-5eaf-02712c0cf045@gmail.com>

 > I've always found the "handle SIGSEGV" command to be sufficient.

Yes, I needed the script because I was debugging the crashes and it was 
necessary to still see any unexpected exceptions.

 > For example, is it handling compiler uncommon traps?

As for the completeness of the script, it works for debugging the 
product I am interested in. See, I didn't claim it will work for 
everyone... :)

From alexandr.miloslavskiy at gmail.com  Wed Sep 11 14:12:16 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Wed, 11 Sep 2019 16:12:16 +0200
Subject: How to native debug Java on macOS?
In-Reply-To: <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
 <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
 <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
Message-ID: <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com>

Yes, I had the same experience, where nothing helped to skip the 
EXC_BAD_ACCESS. Now it just works. I can't explain. Maybe indeed 
something was fixed recently?

$ lldb --version
lldb-1001.0.13.3
   Swift-5.0

From alexandr.miloslavskiy at gmail.com  Wed Sep 11 14:17:22 2019
From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy)
Date: Wed, 11 Sep 2019 16:17:22 +0200
Subject: How to native debug Java on macOS?
In-Reply-To: <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
 <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
 <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
Message-ID: <d65e481d-1d22-60d6-88c8-6787e8916005@gmail.com>

 > putting "process handle" commands in your .lldbinit is pointless

I agree. I now enter the commands manually in every debugging session. 
Boring, but works (now, but not before).

From lois.foltan at oracle.com  Wed Sep 11 15:29:58 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 11 Sep 2019 11:29:58 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
Message-ID: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>

Please review the following change to call is_reference_type() when 
checking if a type is a T_OBJECT or a T_ARRAY.

open webrev at: 
http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
bug link: https://bugs.openjdk.java.net/browse/JDK-8230505

Builds: all tier1 builds, did build with Shenandoah GC, and Solaris builds
Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)

Thanks,
Lois



From coleen.phillimore at oracle.com  Wed Sep 11 16:35:35 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Sep 2019 12:35:35 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
Message-ID: <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>

http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/src/hotspot/share/ci/ciConstant.cpp.udiff.html
http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/src/hotspot/share/classfile/bytecodeAssembler.cpp.udiff.html

Not sure if I agree with the changes to make is_reference_type() called 
in the default label of a case statement.

Wow, there were a lot of these.? The rest of the change looks great.

Thanks,
Coleen


On 9/11/19 11:29 AM, Lois Foltan wrote:
> Please review the following change to call is_reference_type() when 
> checking if a type is a T_OBJECT or a T_ARRAY.
>
> open webrev at: 
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>
> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
> builds
> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>
> Thanks,
> Lois
>
>


From harold.seigel at oracle.com  Wed Sep 11 16:44:50 2019
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 11 Sep 2019 12:44:50 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
Message-ID: <a786fea0-7c19-7db0-0ae5-5398b9924236@oracle.com>

Hi Lois,

It looks good.? Can you change the message in the assert at line 874 in 
heapShared.cpp to something like "can archive only fields that are 
references".

Thanks,? Harold

On 9/11/2019 11:29 AM, Lois Foltan wrote:
> Please review the following change to call is_reference_type() when 
> checking if a type is a T_OBJECT or a T_ARRAY.
>
> open webrev at: 
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>
> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
> builds
> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>
> Thanks,
> Lois
>
>

From chris.plummer at oracle.com  Wed Sep 11 17:23:59 2019
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 11 Sep 2019 10:23:59 -0700
Subject: How to native debug Java on macOS?
In-Reply-To: <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
 <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
 <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
 <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com>
Message-ID: <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com>

On 9/11/19 7:12 AM, Alexander Miloslavskiy wrote:
> Yes, I had the same experience, where nothing helped to skip the 
> EXC_BAD_ACCESS. Now it just works. I can't explain. Maybe indeed 
> something was fixed recently?
>
> $ lldb --version
> lldb-1001.0.13.3
> ? Swift-5.0
That's the same version I'm using. Are you using it from xcode? If so, 
what version of xcode are you using?

Chris


From lois.foltan at oracle.com  Wed Sep 11 18:55:12 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 11 Sep 2019 14:55:12 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>
Message-ID: <2ef00378-7942-f623-dc10-1c732fe5987c@oracle.com>

On 9/11/2019 12:35 PM, coleen.phillimore at oracle.com wrote:
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/src/hotspot/share/ci/ciConstant.cpp.udiff.html 
>
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/src/hotspot/share/classfile/bytecodeAssembler.cpp.udiff.html 
>
>
> Not sure if I agree with the changes to make is_reference_type() 
> called in the default label of a case statement.

Thanks Coleen for the review.? I too share your concern about calling 
is_reference_type in the default label of the case statement, however I 
plan to leave as-is because it does allow for future reference types 
like potentially valhalla inline types.

Lois

>
> Wow, there were a lot of these.? The rest of the change looks great.
>
> Thanks,
> Coleen
>
>
> On 9/11/19 11:29 AM, Lois Foltan wrote:
>> Please review the following change to call is_reference_type() when 
>> checking if a type is a T_OBJECT or a T_ARRAY.
>>
>> open webrev at: 
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
>> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>>
>> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
>> builds
>> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>>
>> Thanks,
>> Lois
>>
>>
>


From lois.foltan at oracle.com  Wed Sep 11 18:56:06 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 11 Sep 2019 14:56:06 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <a786fea0-7c19-7db0-0ae5-5398b9924236@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <a786fea0-7c19-7db0-0ae5-5398b9924236@oracle.com>
Message-ID: <fc65f12d-5399-63a2-84e9-14d857f014fb@oracle.com>

On 9/11/2019 12:44 PM, Harold Seigel wrote:
> Hi Lois,
>
> It looks good.? Can you change the message in the assert at line 874 
> in heapShared.cpp to something like "can archive only fields that are 
> references".

Thanks Harold for the review.? I will make that change prior to commit.
Lois

>
> Thanks,? Harold
>
> On 9/11/2019 11:29 AM, Lois Foltan wrote:
>> Please review the following change to call is_reference_type() when 
>> checking if a type is a T_OBJECT or a T_ARRAY.
>>
>> open webrev at: 
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
>> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>>
>> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
>> builds
>> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>>
>> Thanks,
>> Lois
>>
>>


From john.r.rose at oracle.com  Wed Sep 11 20:06:01 2019
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Sep 2019 13:06:01 -0700
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <2ef00378-7942-f623-dc10-1c732fe5987c@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>
 <2ef00378-7942-f623-dc10-1c732fe5987c@oracle.com>
Message-ID: <97C8D638-EAEE-4C87-96C8-F442A3262A43@oracle.com>

On Sep 11, 2019, at 11:55 AM, Lois Foltan <lois.foltan at oracle.com> wrote:
> 
> Thanks Coleen for the review.  I too share your concern about calling is_reference_type in the default label of the case statement, however I plan to leave as-is because it does allow for future reference types like potentially valhalla inline types.

This function was introduced as an alternative to editing many switch statements when a new type of reference is introduced in Valhalla.  So even though the fix disrupts the clarity of some switches, it?s belongs as part of this change.

The other uses are also helpful, and would have prevented a number of historical bugs (of the form ?I forget T_ARRAY?) if we had adopted the practice from the first.  Maybe that?s another reason to look at the switches as something to change rather than keep.

? John



From per.liden at oracle.com  Wed Sep 11 20:37:55 2019
From: per.liden at oracle.com (Per Liden)
Date: Wed, 11 Sep 2019 22:37:55 +0200
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
Message-ID: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>

ZGC uses thread locals in a number of places. It's currently using using 
the gcc specific __thread, but we'd like to make that compiler agnostic. 
We currently have the THREAD_LOCAL_DECL macro, which does what we want. 
However, I propose that we rename THREAD_LOCAL_DECL to thread_local, for 
the following reasons:

* In C+11, thread_local was standardized. When we upgrade to C++1X, we 
can just remove our own thread_local macros, without the need to touch 
any other code.

* The thread_local keyword is recognized by IDEs/editors, so gets 
correctly highlighted, etc.

* THREAD_LOCAL_DECL looks a bit clunky in declarations (IMHO).

About the patch:

* USE_LIBRARY_BASED_TLS_ONLY now only controls how Thread::current() is 
implemented, not whether thread_local should be defined or not.

* We define thread_local on gcc/clang/solstudio, if we're using a 
pre-C++11 compiler.

* We don't define thread_local on xlc, since thread_local will never be 
used anyway because it currently always defines 
USE_LIBRARY_BASED_TLS_ONLY to 1.

* We don't define thread_local on VS2017, since it's already supported 
with that compiler.

Bug: https://bugs.openjdk.java.net/browse/JDK-8230877
Webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.0

Testing: Builds on all Oracle supported platforms

/Per

From dean.long at oracle.com  Wed Sep 11 20:38:34 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 11 Sep 2019 13:38:34 -0700
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
Message-ID: <355f0f87-c158-f730-2061-fbdfb94ca527@oracle.com>

This makes me wish we could call BasicType::is_reference_type() :-)

I was going to suggest replacing the small number of 
"is_reference_type(result->get_type()))" with 
"result->is_reference_type()", but maybe it's not worth adding a helper 
method for so few uses.? It does look more "OO" however.

dl

On 9/11/19 8:29 AM, Lois Foltan wrote:
> Please review the following change to call is_reference_type() when 
> checking if a type is a T_OBJECT or a T_ARRAY.
>
> open webrev at: 
> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>
> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
> builds
> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>
> Thanks,
> Lois
>
>


From coleen.phillimore at oracle.com  Wed Sep 11 20:44:19 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Sep 2019 16:44:19 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <97C8D638-EAEE-4C87-96C8-F442A3262A43@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>
 <2ef00378-7942-f623-dc10-1c732fe5987c@oracle.com>
 <97C8D638-EAEE-4C87-96C8-F442A3262A43@oracle.com>
Message-ID: <ee9f5eab-44d0-563a-bef9-7bd72cf9195c@oracle.com>



On 9/11/19 4:06 PM, John Rose wrote:
> On Sep 11, 2019, at 11:55 AM, Lois Foltan <lois.foltan at oracle.com 
> <mailto:lois.foltan at oracle.com>> wrote:
>>
>> Thanks Coleen for the review.? I too share your concern about calling 
>> is_reference_type in the default label of the case statement, however 
>> I plan to leave as-is because it does allow for future reference 
>> types like potentially valhalla inline types.
>
> This function was introduced as an alternative to editing many switch 
> statements when a new type of reference is introduced in Valhalla. ?So 
> even though the fix disrupts the clarity of some switches, it?s 
> belongs as part of this change.
>
> The other uses are also helpful, and would have prevented a number of 
> historical bugs (of the form ?I forget T_ARRAY?) if we had adopted the 
> practice from the first. ?Maybe that?s another reason to look at the 
> switches as something to change rather than keep.

I think if you add a new T_SOME_REFERENCE_TYPE, you're going to have to 
find and possibly change all these switch statements regardless of this 
change, and this is going to break your flow.

coleen$ grep -r "case T_OBJECT" | wc -l
67

This only changes 2 of them.?? I like this rest of this change enough 
that I won't really argue if you want to leave it, but it's going to 
cause someone to waste some mental energy down the line anyway.

thanks,
Coleen
>
> ? John
>
>


From coleen.phillimore at oracle.com  Wed Sep 11 20:45:45 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 11 Sep 2019 16:45:45 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <ee9f5eab-44d0-563a-bef9-7bd72cf9195c@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <7471dc58-32a9-6137-d465-9e2af202030e@oracle.com>
 <2ef00378-7942-f623-dc10-1c732fe5987c@oracle.com>
 <97C8D638-EAEE-4C87-96C8-F442A3262A43@oracle.com>
 <ee9f5eab-44d0-563a-bef9-7bd72cf9195c@oracle.com>
Message-ID: <dcfb3da0-40b6-57c8-a439-524c9fe8c18f@oracle.com>



On 9/11/19 4:44 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 9/11/19 4:06 PM, John Rose wrote:
>> On Sep 11, 2019, at 11:55 AM, Lois Foltan <lois.foltan at oracle.com 
>> <mailto:lois.foltan at oracle.com>> wrote:
>>>
>>> Thanks Coleen for the review.? I too share your concern about 
>>> calling is_reference_type in the default label of the case 
>>> statement, however I plan to leave as-is because it does allow for 
>>> future reference types like potentially valhalla inline types.
>>
>> This function was introduced as an alternative to editing many switch 
>> statements when a new type of reference is introduced in Valhalla. 
>> ?So even though the fix disrupts the clarity of some switches, it?s 
>> belongs as part of this change.
>>
>> The other uses are also helpful, and would have prevented a number of 
>> historical bugs (of the form ?I forget T_ARRAY?) if we had adopted 
>> the practice from the first. ?Maybe that?s another reason to look at 
>> the switches as something to change rather than keep.
>
> I think if you add a new T_SOME_REFERENCE_TYPE, you're going to have 
> to find and possibly change all these switch statements regardless of 
> this change, and this is going to break your flow.
>
> coleen$ grep -r "case T_OBJECT" | wc -l
> 67
>

coleen$ grep -r "case T_OBJECT" | wc -l
200

I was on the wrong directory level...

Coleen

> This only changes 2 of them.?? I like this rest of this change enough 
> that I won't really argue if you want to leave it, but it's going to 
> cause someone to waste some mental energy down the line anyway.
>
> thanks,
> Coleen
>>
>> ? John
>>
>>
>


From kim.barrett at oracle.com  Wed Sep 11 21:37:14 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Sep 2019 17:37:14 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
Message-ID: <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>

> On Sep 11, 2019, at 4:37 PM, Per Liden <per.liden at oracle.com> wrote:
> 
> ZGC uses thread locals in a number of places. It's currently using using the gcc specific __thread, but we'd like to make that compiler agnostic. We currently have the THREAD_LOCAL_DECL macro, which does what we want. However, I propose that we rename THREAD_LOCAL_DECL to thread_local, for the following reasons:
> 
> * In C+11, thread_local was standardized. When we upgrade to C++1X, we can just remove our own thread_local macros, without the need to touch any other code.
> 
> * The thread_local keyword is recognized by IDEs/editors, so gets correctly highlighted, etc.
> 
> * THREAD_LOCAL_DECL looks a bit clunky in declarations (IMHO).
> 
> About the patch:
> 
> * USE_LIBRARY_BASED_TLS_ONLY now only controls how Thread::current() is implemented, not whether thread_local should be defined or not.
> 
> * We define thread_local on gcc/clang/solstudio, if we're using a pre-C++11 compiler.
> 
> * We don't define thread_local on xlc, since thread_local will never be used anyway because it currently always defines USE_LIBRARY_BASED_TLS_ONLY to 1.
> 
> * We don't define thread_local on VS2017, since it's already supported with that compiler.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230877
> Webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.0
> 
> Testing: Builds on all Oracle supported platforms
> 
> /Per

Sorry for misleading you in our earlier off-line discussion. I forgot about 
older versions of VS. 

For Visual Studio, while we (Oracle) no longer build jdk/jdk with anything
older than VS2017 (which unconditionally provides C++11 thread_local), other
people may still be building with older versions of VS. (That will have to
change when we start using C++11/14 features, but until then we've not been
pruning older versions from the set that's permitted, which includes some
pretty old versions.)

And checking __cplusplus (like we're doing on other platforms) seems to be a
bit of a mess for VS:
https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/

Instead for VS we probably need to do an MSVC version check to decide
whether to define thread_local to __declspec(thread), but I don't know which
version of VS starts providing it natively.  Either that or prune the set of
(at least purportedly) supported versions somewhat.



From kim.barrett at oracle.com  Wed Sep 11 22:12:49 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Sep 2019 18:12:49 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
Message-ID: <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>

> On Sep 11, 2019, at 5:37 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> Instead for VS we probably need to do an MSVC version check to decide
> whether to define thread_local to __declspec(thread), but I don't know which
> version of VS starts providing it natively.  Either that or prune the set of
> (at least purportedly) supported versions somewhat.

According to boost.config and various other places I found, it appears
thread_local first shows up in Visual Studio 2015. So having a
__declspec(thread) definition protected with "#if _MSC_VER < 1900" should do
the trick.


From david.holmes at oracle.com  Wed Sep 11 22:19:10 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 08:19:10 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
 <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>
Message-ID: <36625e89-2ad6-ac3a-ec23-988774b2337f@oracle.com>

Hi Dan,

Are you okay with this?

Thanks,
David

On 10/09/2019 7:41 am, David Holmes wrote:
> Hi Dan,
> 
> Thanks for taking a look.
> 
> On 10/09/2019 3:27 am, Daniel D. Daugherty wrote:
>> On 9/9/19 1:21 AM, David Holmes wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>
>> src/hotspot/cpu/x86/rdtsc_x86.cpp
>> ???? No comments.
>>
>> src/hotspot/os/posix/os_posix.cpp
>> ???? L648: ? assert(thread->is_Java_thread(), "invariant");
>> ???? L649: ? JavaThread* jt = (JavaThread*) thread;
>> ???????? I was expecting this change with your "interrupt" bug.
>> ???????? Are we ready for this assert() now?
>>
>> src/hotspot/os/windows/os_windows.cpp
>> ???? L3600: ? assert(thread->is_Java_thread(), "invariant");
>> ???? L3601: ? JavaThread* jt = (JavaThread*) thread;
>> ???????? I was expecting this change with your "interrupt" bug.
>> ???????? Are we ready for this assert() now?
> 
> It is already true that only JavaThreads use the interrupt facility. The 
> forthcoming changes to the interrupt just make that more obvious:
> 
> os::interrupt is-called-from
>  ? Thread::interrupt is called from
>  ??? JVM_Interrupt? // java.lang.Thread interrupt
>  ??? JvmtiEnv::InterruptThread // JVM TI InterruptThread
>  ??? JavaThread::send_thread_stop
> 
> so always applied to a JavaThread.
> 
>> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
>> ???? No comments.
>>
>> src/hotspot/share/jvmci/jvmciCompiler.cpp
>> ???? No comments.
>>
>> src/hotspot/share/jvmci/jvmciRuntime.cpp
>> ???? No comments.
>>
>> src/hotspot/share/prims/jvm.cpp
>> ???? No comments.
>>
>> src/hotspot/share/runtime/os.cpp
>> ???? No comments.
>>
>> src/hotspot/share/runtime/os.hpp
>> ???? No comments.
>>
>> src/hotspot/share/runtime/thread.cpp
>> ???? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
>> ???? L1815: ? _SleepEvent? = NULL;
>> ???????? nit - please delete extra blank before '='.
>>
>> ???? L3403 - nit - please delete extra blank line.
> 
> Nits will be fixed.
> 
> Thanks,
> David
> -----
> 
>> src/hotspot/share/runtime/thread.hpp
>> ???? No comments.
>>
>> test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
>> ???? No comments.
>>
>> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
>> ???? No comments.
>>
>> test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
>> ???? No comments.
>>
>>
>> Thumbs up! I don't need to see a new webrev if you decide to
>> fix the nits.
>>
>> Dan
>>
>>
>>>
>>> This is the next step in the sleep/interrupt support code reshuffle. 
>>> Now that os::sleep is platform independent and only applicable to 
>>> JavaThreads, we can move it to JavaThread as an instance method.
>>>
>>> Summary of changes:
>>> - os::sleep moved to JavaThread::sleep as instance method
>>> - signature changed to return bool - true means timed-out; false 
>>> means interrupted
>>> - rearranged the sleep code slightly to remove the initial 
>>> back-to-back nanoTime() calls - as suggested by Roger.
>>> - _SleepEvent moved from Thread to JavaThread
>>> - minor changes to os::interrupt to account for move to JavaThread 
>>> (this code will also be moved to JavaThread in the next fix)
>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>
>>> Testing:
>>> ?- tiers 1-3
>>>
>>> Thanks,
>>> David
>>

From per.liden at oracle.com  Wed Sep 11 22:23:51 2019
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Sep 2019 00:23:51 +0200
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
Message-ID: <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>

On 9/12/19 12:12 AM, Kim Barrett wrote:
>> On Sep 11, 2019, at 5:37 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> Instead for VS we probably need to do an MSVC version check to decide
>> whether to define thread_local to __declspec(thread), but I don't know which
>> version of VS starts providing it natively.  Either that or prune the set of
>> (at least purportedly) supported versions somewhat.
> 
> According to boost.config and various other places I found, it appears
> thread_local first shows up in Visual Studio 2015. So having a
> __declspec(thread) definition protected with "#if _MSC_VER < 1900" should do
> the trick.
> 

I sort of came to the same conclusion. According to this table [1], 
there's "Partial" support in VS2010, and full support in VS2015. No 
details on what "Partial" means. Some additional googling vaguely 
suggests that "Partial" refers to support for "__declspec(thread)" and 
full support would be "thread_local", but I can't find any official 
document saying that.

Defining thread_local for pre-VS2015 (_MSC_VER < 1900) seems like a 
reasonable way forward.

Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.1

/Per

[1] 
https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?redirectedfrom=MSDN#c11-core-language-features-table-concurrency

From daniel.daugherty at oracle.com  Wed Sep 11 22:26:44 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 11 Sep 2019 18:26:44 -0400
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <36625e89-2ad6-ac3a-ec23-988774b2337f@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
 <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>
 <36625e89-2ad6-ac3a-ec23-988774b2337f@oracle.com>
Message-ID: <df98d356-c7e0-7e8d-bef1-bf352105d3af@oracle.com>

On 9/11/19 6:19 PM, David Holmes wrote:
> Hi Dan,
>
> Are you okay with this?

Yes... at the bottom of that review I put:

> Thumbs up! I don't need to see a new webrev if you decide to
> fix the nits. 

so I didn't think I needed to reply to your filling in
the query about interrupts and JavaThread*...

Dan


>
> Thanks,
> David
>
> On 10/09/2019 7:41 am, David Holmes wrote:
>> Hi Dan,
>>
>> Thanks for taking a look.
>>
>> On 10/09/2019 3:27 am, Daniel D. Daugherty wrote:
>>> On 9/9/19 1:21 AM, David Holmes wrote:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>
>>> src/hotspot/cpu/x86/rdtsc_x86.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/os/posix/os_posix.cpp
>>> ???? L648: ? assert(thread->is_Java_thread(), "invariant");
>>> ???? L649: ? JavaThread* jt = (JavaThread*) thread;
>>> ???????? I was expecting this change with your "interrupt" bug.
>>> ???????? Are we ready for this assert() now?
>>>
>>> src/hotspot/os/windows/os_windows.cpp
>>> ???? L3600: ? assert(thread->is_Java_thread(), "invariant");
>>> ???? L3601: ? JavaThread* jt = (JavaThread*) thread;
>>> ???????? I was expecting this change with your "interrupt" bug.
>>> ???????? Are we ready for this assert() now?
>>
>> It is already true that only JavaThreads use the interrupt facility. 
>> The forthcoming changes to the interrupt just make that more obvious:
>>
>> os::interrupt is-called-from
>> ?? Thread::interrupt is called from
>> ???? JVM_Interrupt? // java.lang.Thread interrupt
>> ???? JvmtiEnv::InterruptThread // JVM TI InterruptThread
>> ???? JavaThread::send_thread_stop
>>
>> so always applied to a JavaThread.
>>
>>> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/jvmci/jvmciCompiler.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/jvmci/jvmciRuntime.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/prims/jvm.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/runtime/os.cpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/runtime/os.hpp
>>> ???? No comments.
>>>
>>> src/hotspot/share/runtime/thread.cpp
>>> ???? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
>>> ???? L1815: ? _SleepEvent? = NULL;
>>> ???????? nit - please delete extra blank before '='.
>>>
>>> ???? L3403 - nit - please delete extra blank line.
>>
>> Nits will be fixed.
>>
>> Thanks,
>> David
>> -----
>>
>>> src/hotspot/share/runtime/thread.hpp
>>> ???? No comments.
>>>
>>> test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
>>> ???? No comments.
>>>
>>> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
>>> ???? No comments.
>>>
>>> test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
>>> ???? No comments.
>>>
>>>
>>> Thumbs up! I don't need to see a new webrev if you decide to
>>> fix the nits.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> This is the next step in the sleep/interrupt support code 
>>>> reshuffle. Now that os::sleep is platform independent and only 
>>>> applicable to JavaThreads, we can move it to JavaThread as an 
>>>> instance method.
>>>>
>>>> Summary of changes:
>>>> - os::sleep moved to JavaThread::sleep as instance method
>>>> - signature changed to return bool - true means timed-out; false 
>>>> means interrupted
>>>> - rearranged the sleep code slightly to remove the initial 
>>>> back-to-back nanoTime() calls - as suggested by Roger.
>>>> - _SleepEvent moved from Thread to JavaThread
>>>> - minor changes to os::interrupt to account for move to JavaThread 
>>>> (this code will also be moved to JavaThread in the next fix)
>>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>>
>>>> Testing:
>>>> ?- tiers 1-3
>>>>
>>>> Thanks,
>>>> David
>>>


From kim.barrett at oracle.com  Wed Sep 11 22:58:03 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Sep 2019 18:58:03 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
Message-ID: <3B8FD799-2994-43FD-9EE4-2D3B3AA3B19F@oracle.com>

> On Sep 11, 2019, at 6:23 PM, Per Liden <per.liden at oracle.com> wrote:
> 
> On 9/12/19 12:12 AM, Kim Barrett wrote:
>>> On Sep 11, 2019, at 5:37 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> Instead for VS we probably need to do an MSVC version check to decide
>>> whether to define thread_local to __declspec(thread), but I don't know which
>>> version of VS starts providing it natively.  Either that or prune the set of
>>> (at least purportedly) supported versions somewhat.
>> According to boost.config and various other places I found, it appears
>> thread_local first shows up in Visual Studio 2015. So having a
>> __declspec(thread) definition protected with "#if _MSC_VER < 1900" should do
>> the trick.
> 
> I sort of came to the same conclusion. According to this table [1], there's "Partial" support in VS2010, and full support in VS2015. No details on what "Partial" means. Some additional googling vaguely suggests that "Partial" refers to support for "__declspec(thread)" and full support would be "thread_local", but I can't find any official document saying that.
> 
> Defining thread_local for pre-VS2015 (_MSC_VER < 1900) seems like a reasonable way forward.
> 
> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.1
> 
> /Per
> 
> [1] https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?redirectedfrom=MSDN#c11-core-language-features-table-concurrency

Looks good.


From david.holmes at oracle.com  Wed Sep 11 22:58:16 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 08:58:16 +1000
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
Message-ID: <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>

Hi Per,

So if I read this right, the renaming will cause the C++11 thread_local 
to be used always on Windows (due to our use of VS 2017) but for Solaris 
Studio and gcc it will only be enabled if we explicitly ask for C++11 
support - is that right?

I see Windows Visual Studio and Solaris Studio clearly state the 
equivalence of the two mechanisms. I'm expecting gcc is the same, but I 
don't see that clearly stated.

Thanks,
David

On 12/09/2019 8:23 am, Per Liden wrote:
> On 9/12/19 12:12 AM, Kim Barrett wrote:
>>> On Sep 11, 2019, at 5:37 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>> Instead for VS we probably need to do an MSVC version check to decide
>>> whether to define thread_local to __declspec(thread), but I don't 
>>> know which
>>> version of VS starts providing it natively.? Either that or prune the 
>>> set of
>>> (at least purportedly) supported versions somewhat.
>>
>> According to boost.config and various other places I found, it appears
>> thread_local first shows up in Visual Studio 2015. So having a
>> __declspec(thread) definition protected with "#if _MSC_VER < 1900" 
>> should do
>> the trick.
>>
> 
> I sort of came to the same conclusion. According to this table [1], 
> there's "Partial" support in VS2010, and full support in VS2015. No 
> details on what "Partial" means. Some additional googling vaguely 
> suggests that "Partial" refers to support for "__declspec(thread)" and 
> full support would be "thread_local", but I can't find any official 
> document saying that.
> 
> Defining thread_local for pre-VS2015 (_MSC_VER < 1900) seems like a 
> reasonable way forward.
> 
> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.1
> 
> /Per
> 
> [1] 
> https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?redirectedfrom=MSDN#c11-core-language-features-table-concurrency 
> 

From david.holmes at oracle.com  Wed Sep 11 23:21:28 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 09:21:28 +1000
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <df98d356-c7e0-7e8d-bef1-bf352105d3af@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
 <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>
 <36625e89-2ad6-ac3a-ec23-988774b2337f@oracle.com>
 <df98d356-c7e0-7e8d-bef1-bf352105d3af@oracle.com>
Message-ID: <80e05cee-ccc4-d27a-d6e2-72314636ec1a@oracle.com>

On 12/09/2019 8:26 am, Daniel D. Daugherty wrote:
> On 9/11/19 6:19 PM, David Holmes wrote:
>> Hi Dan,
>>
>> Are you okay with this?
> 
> Yes... at the bottom of that review I put:
> 
>> Thumbs up! I don't need to see a new webrev if you decide to
>> fix the nits. 
> 
> so I didn't think I needed to reply to your filling in
> the query about interrupts and JavaThread*...

I wanted to be sure my answer didn't prompt additional concerns.

Thanks,
David
-----

> Dan
> 
> 
>>
>> Thanks,
>> David
>>
>> On 10/09/2019 7:41 am, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Thanks for taking a look.
>>>
>>> On 10/09/2019 3:27 am, Daniel D. Daugherty wrote:
>>>> On 9/9/19 1:21 AM, David Holmes wrote:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>>
>>>> src/hotspot/cpu/x86/rdtsc_x86.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/os/posix/os_posix.cpp
>>>> ???? L648: ? assert(thread->is_Java_thread(), "invariant");
>>>> ???? L649: ? JavaThread* jt = (JavaThread*) thread;
>>>> ???????? I was expecting this change with your "interrupt" bug.
>>>> ???????? Are we ready for this assert() now?
>>>>
>>>> src/hotspot/os/windows/os_windows.cpp
>>>> ???? L3600: ? assert(thread->is_Java_thread(), "invariant");
>>>> ???? L3601: ? JavaThread* jt = (JavaThread*) thread;
>>>> ???????? I was expecting this change with your "interrupt" bug.
>>>> ???????? Are we ready for this assert() now?
>>>
>>> It is already true that only JavaThreads use the interrupt facility. 
>>> The forthcoming changes to the interrupt just make that more obvious:
>>>
>>> os::interrupt is-called-from
>>> ?? Thread::interrupt is called from
>>> ???? JVM_Interrupt? // java.lang.Thread interrupt
>>> ???? JvmtiEnv::InterruptThread // JVM TI InterruptThread
>>> ???? JavaThread::send_thread_stop
>>>
>>> so always applied to a JavaThread.
>>>
>>>> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/jvmci/jvmciCompiler.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/jvmci/jvmciRuntime.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/prims/jvm.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/runtime/os.cpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/runtime/os.hpp
>>>> ???? No comments.
>>>>
>>>> src/hotspot/share/runtime/thread.cpp
>>>> ???? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
>>>> ???? L1815: ? _SleepEvent? = NULL;
>>>> ???????? nit - please delete extra blank before '='.
>>>>
>>>> ???? L3403 - nit - please delete extra blank line.
>>>
>>> Nits will be fixed.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> src/hotspot/share/runtime/thread.hpp
>>>> ???? No comments.
>>>>
>>>> test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
>>>> ???? No comments.
>>>>
>>>> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
>>>> ???? No comments.
>>>>
>>>> test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
>>>> ???? No comments.
>>>>
>>>>
>>>> Thumbs up! I don't need to see a new webrev if you decide to
>>>> fix the nits.
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> This is the next step in the sleep/interrupt support code 
>>>>> reshuffle. Now that os::sleep is platform independent and only 
>>>>> applicable to JavaThreads, we can move it to JavaThread as an 
>>>>> instance method.
>>>>>
>>>>> Summary of changes:
>>>>> - os::sleep moved to JavaThread::sleep as instance method
>>>>> - signature changed to return bool - true means timed-out; false 
>>>>> means interrupted
>>>>> - rearranged the sleep code slightly to remove the initial 
>>>>> back-to-back nanoTime() calls - as suggested by Roger.
>>>>> - _SleepEvent moved from Thread to JavaThread
>>>>> - minor changes to os::interrupt to account for move to JavaThread 
>>>>> (this code will also be moved to JavaThread in the next fix)
>>>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>>>
>>>>> Testing:
>>>>> ?- tiers 1-3
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
> 

From daniel.daugherty at oracle.com  Wed Sep 11 23:36:10 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 11 Sep 2019 19:36:10 -0400
Subject: RFR (S): 8230423: Move os::sleep to JavaThread::sleep
In-Reply-To: <80e05cee-ccc4-d27a-d6e2-72314636ec1a@oracle.com>
References: <eca626a9-188c-d496-8ba2-2b722c230f8a@oracle.com>
 <ce5b838e-abbf-0804-e978-63bb009fc78c@oracle.com>
 <dc855ab4-e592-9d8e-5184-cb1334dec533@oracle.com>
 <36625e89-2ad6-ac3a-ec23-988774b2337f@oracle.com>
 <df98d356-c7e0-7e8d-bef1-bf352105d3af@oracle.com>
 <80e05cee-ccc4-d27a-d6e2-72314636ec1a@oracle.com>
Message-ID: <c57393f5-c90b-b37d-c916-1e954bcae7db@oracle.com>

On 9/11/19 7:21 PM, David Holmes wrote:
> On 12/09/2019 8:26 am, Daniel D. Daugherty wrote:
>> On 9/11/19 6:19 PM, David Holmes wrote:
>>> Hi Dan,
>>>
>>> Are you okay with this?
>>
>> Yes... at the bottom of that review I put:
>>
>>> Thumbs up! I don't need to see a new webrev if you decide to
>>> fix the nits. 
>>
>> so I didn't think I needed to reply to your filling in
>> the query about interrupts and JavaThread*...
>
> I wanted to be sure my answer didn't prompt additional concerns.

None from me.

Dan


>
> Thanks,
> David
> -----
>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 10/09/2019 7:41 am, David Holmes wrote:
>>>> Hi Dan,
>>>>
>>>> Thanks for taking a look.
>>>>
>>>> On 10/09/2019 3:27 am, Daniel D. Daugherty wrote:
>>>>> On 9/9/19 1:21 AM, David Holmes wrote:
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8230423
>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8230423/webrev/
>>>>>
>>>>> src/hotspot/cpu/x86/rdtsc_x86.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/os/posix/os_posix.cpp
>>>>> ???? L648: ? assert(thread->is_Java_thread(), "invariant");
>>>>> ???? L649: ? JavaThread* jt = (JavaThread*) thread;
>>>>> ???????? I was expecting this change with your "interrupt" bug.
>>>>> ???????? Are we ready for this assert() now?
>>>>>
>>>>> src/hotspot/os/windows/os_windows.cpp
>>>>> ???? L3600: ? assert(thread->is_Java_thread(), "invariant");
>>>>> ???? L3601: ? JavaThread* jt = (JavaThread*) thread;
>>>>> ???????? I was expecting this change with your "interrupt" bug.
>>>>> ???????? Are we ready for this assert() now?
>>>>
>>>> It is already true that only JavaThreads use the interrupt 
>>>> facility. The forthcoming changes to the interrupt just make that 
>>>> more obvious:
>>>>
>>>> os::interrupt is-called-from
>>>> ?? Thread::interrupt is called from
>>>> ???? JVM_Interrupt? // java.lang.Thread interrupt
>>>> ???? JvmtiEnv::InterruptThread // JVM TI InterruptThread
>>>> ???? JavaThread::send_thread_stop
>>>>
>>>> so always applied to a JavaThread.
>>>>
>>>>> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/jvmci/jvmciCompiler.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/jvmci/jvmciRuntime.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/prims/jvm.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/runtime/os.cpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/runtime/os.hpp
>>>>> ???? No comments.
>>>>>
>>>>> src/hotspot/share/runtime/thread.cpp
>>>>> ???? L1701: ? _SleepEvent? = ParkEvent::Allocate(this);
>>>>> ???? L1815: ? _SleepEvent? = NULL;
>>>>> ???????? nit - please delete extra blank before '='.
>>>>>
>>>>> ???? L3403 - nit - please delete extra blank line.
>>>>
>>>> Nits will be fixed.
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> src/hotspot/share/runtime/thread.hpp
>>>>> ???? No comments.
>>>>>
>>>>> test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp
>>>>> ???? No comments.
>>>>>
>>>>> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp
>>>>> ???? No comments.
>>>>>
>>>>> test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
>>>>> ???? No comments.
>>>>>
>>>>>
>>>>> Thumbs up! I don't need to see a new webrev if you decide to
>>>>> fix the nits.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> This is the next step in the sleep/interrupt support code 
>>>>>> reshuffle. Now that os::sleep is platform independent and only 
>>>>>> applicable to JavaThreads, we can move it to JavaThread as an 
>>>>>> instance method.
>>>>>>
>>>>>> Summary of changes:
>>>>>> - os::sleep moved to JavaThread::sleep as instance method
>>>>>> - signature changed to return bool - true means timed-out; false 
>>>>>> means interrupted
>>>>>> - rearranged the sleep code slightly to remove the initial 
>>>>>> back-to-back nanoTime() calls - as suggested by Roger.
>>>>>> - _SleepEvent moved from Thread to JavaThread
>>>>>> - minor changes to os::interrupt to account for move to 
>>>>>> JavaThread (this code will also be moved to JavaThread in the 
>>>>>> next fix)
>>>>>> - call sites changed from os::sleep(t,ms) to t->sleep(ms)
>>>>>>
>>>>>> Testing:
>>>>>> ?- tiers 1-3
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>
>>


From kim.barrett at oracle.com  Wed Sep 11 23:34:36 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Sep 2019 19:34:36 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
Message-ID: <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>

> On Sep 11, 2019, at 6:58 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Per,
> 
> So if I read this right, the renaming will cause the C++11 thread_local to be used always on Windows (due to our use of VS 2017) but for Solaris Studio and gcc it will only be enabled if we explicitly ask for C++11 support - is that right?
> 
> I see Windows Visual Studio and Solaris Studio clearly state the equivalence of the two mechanisms. I'm expecting gcc is the same, but I don't see that clearly stated.

Well, bleh!  Thanks for making me look into that...

The release notes for gcc4.8 [1] (where thread_local support was added)
describes an important performance difference between thread_local and
__thread, and mentions a compiler option to remove that difference under
some circumstances.  It also suggests that because of this, one may want to
stick with __thread where it's still applicable.  (An initializer for a
__thread variable must be a constant expression. [3])

The gcc9.2 manual [2] (latest) describes the relevant option
(-fno-extern-tls-init). Maybe we can use that, but it puts some non-standard
(and well hidden) restrictions on our use of thread_local, which somewhat
defeats the point.

[1] https://gcc.gnu.org/gcc-4.8/changes.html 
[2] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C_002b_002b-Dialect-Options.html#index-fextern-tls-init
[3] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Thread-Local.html#Thread-Local

Retracting my "Looks good?.  Fooey!



From david.holmes at oracle.com  Wed Sep 11 23:46:18 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 09:46:18 +1000
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
Message-ID: <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>

Hi Kim,

On 12/09/2019 9:34 am, Kim Barrett wrote:
>> On Sep 11, 2019, at 6:58 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Per,
>>
>> So if I read this right, the renaming will cause the C++11 thread_local to be used always on Windows (due to our use of VS 2017) but for Solaris Studio and gcc it will only be enabled if we explicitly ask for C++11 support - is that right?
>>
>> I see Windows Visual Studio and Solaris Studio clearly state the equivalence of the two mechanisms. I'm expecting gcc is the same, but I don't see that clearly stated.
> 
> Well, bleh!  Thanks for making me look into that...

:) If it wasn't for the unconditional use of thread_local in Visual 
Studio I wouldn't have dived deeper either.

> The release notes for gcc4.8 [1] (where thread_local support was added)
> describes an important performance difference between thread_local and
> __thread, and mentions a compiler option to remove that difference under
> some circumstances.  It also suggests that because of this, one may want to
> stick with __thread where it's still applicable.  (An initializer for a
> __thread variable must be a constant expression. [3])
> 
> The gcc9.2 manual [2] (latest) describes the relevant option
> (-fno-extern-tls-init). Maybe we can use that, but it puts some non-standard
> (and well hidden) restrictions on our use of thread_local, which somewhat
> defeats the point.
> 
> [1] https://gcc.gnu.org/gcc-4.8/changes.html
> [2] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C_002b_002b-Dialect-Options.html#index-fextern-tls-init
> [3] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Thread-Local.html#Thread-Local
> 
> Retracting my "Looks good?.  Fooey!

But as we are not actually enabling this as we don't turn on C++11, 
surely this still "looks good" enough? But we will have to look closer 
at things before turning it on? We may need to clarify our own rules for 
using thread-locals if we find there is a performance hit and we want to 
use the magic flag.

David

> 

From kim.barrett at oracle.com  Thu Sep 12 00:04:06 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 11 Sep 2019 20:04:06 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
Message-ID: <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>

> On Sep 11, 2019, at 7:46 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> But as we are not actually enabling this as we don't turn on C++11, surely this still "looks good" enough? But we will have to look closer at things before turning it on? We may need to clarify our own rules for using thread-locals if we find there is a performance hit and we want to use the magic flag.

Part of the rationale for renaming to thread_local was that the
transition to C++11 was trivial.  But apparently not so.

I really don't want to be tripping over this hidden performance hit
when trying to throw the language standard switch.  (Assuming it's
measurable, but we hit Thread::current() quite a bit, and ZGC has a
bunch of thread-local variables pretty baked in and used fairly
heavily I think.)  I do not want this little syntactic nicety to be an
argument for not throwing that switch.

And in the long run, I'd prefer a different name if we're going to
effectively have non-standard semantics (because of the usage
restrictions required by that compiler flag).


From chris.plummer at oracle.com  Thu Sep 12 04:26:29 2019
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 11 Sep 2019 21:26:29 -0700
Subject: How to native debug Java on macOS?
In-Reply-To: <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com>
References: <e0d0dfcd-6c39-108b-a449-80583daba99a@gmail.com>
 <61EF4CF8-F905-4B1C-99AB-DA5AB8628CE8@oracle.com>
 <ddaca140-2057-400d-3d31-79adaf3ff8e4@gmail.com>
 <4e0c2830-b4d9-a7d2-4a8d-6cce5ca79a66@oracle.com>
 <3dd8cac1-230c-ed1f-7ec5-0caf1bc6ffaf@gmail.com>
 <0d15bff8-99db-52e9-3ec2-6b12b83d4902@oracle.com>
Message-ID: <7ae8e585-59c4-8e7f-b1a4-415f4d82f7c0@oracle.com>

On 9/11/19 10:23 AM, Chris Plummer wrote:
> On 9/11/19 7:12 AM, Alexander Miloslavskiy wrote:
>> Yes, I had the same experience, where nothing helped to skip the 
>> EXC_BAD_ACCESS. Now it just works. I can't explain. Maybe indeed 
>> something was fixed recently?
>>
>> $ lldb --version
>> lldb-1001.0.13.3
>> ? Swift-5.0
> That's the same version I'm using. Are you using it from xcode? If so, 
> what version of xcode are you using?
>
> Chris
>
I wonder if what's actually changed is how or what you are debugging. 
Possibly you simply aren't hitting any of the segv traps, especially if? 
you are waiting for the program to warm up before attaching, or are only 
debugging for a short period of time. Debugging an app that pretty much 
is only ever executing on 1 thread at a time also reduces the likelyhood 
of traps. Have you tried first reproducing the issue without "process 
handle", and then go through the exact same step with "process handle"?

Chris


From david.holmes at oracle.com  Thu Sep 12 04:33:35 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 14:33:35 +1000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>

Hi Christoph,

On 11/09/2019 11:25 pm, Langer, Christoph wrote:
> Hi,
> 
> please review this cleanup in test.lib.
> 
> One part is the removal/cleanup of @SuppressWarnings annotations. Some are unnecessary and in Utils.java an unchecked warning can be quiesced.

So in:

test/lib/jdk/test/lib/Platform.java
test/lib/jdk/test/lib/process/ProcessTools.java

in this code

               } catch (PrivilegedActionException e) {
-                 @SuppressWarnings("unchecked")
                   IOException t = (IOException) e.getException();

I take it these are unnecessary as these casts are not unchecked casts?

---

test/lib/jdk/test/lib/Utils.java

No comments.

---

test/lib/jdk/test/lib/process/ProcessTools.java

-     @SuppressWarnings("overloads")
       public static Process startProcess(String name,
                                          ProcessBuilder processBuilder,
                                          final Predicate<String> 
linePredicate)

Unnecessary? I can't find what this warning is supposed to mean. Is it 
used by some IDE's?

> Furthermore, when analyzing some test outputs lately, I got annoyed by stack traces like the following when using jdk.test.lib.process.StreamPumper. I think they are of no particular value and could be suppressed.
> 
> java.io.IOException: Stream closed
> at java.base/java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:169)
> at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:335)
> at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
> at java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:285)
> at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
> at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:109)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.lang.Thread.run(Thread.java:830)

Ok. Seems a bit crude, but then the StreamPumper code is crude - just 
running till it hits an exception, but an exception is the only way it 
will detect an async close of the stream.

Thanks,
David
-----

> Bug: https://bugs.openjdk.java.net/browse/JDK-8230854
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8230854.0/
> 
> Thanks
> Christoph
> 

From thomas.stuefe at gmail.com  Thu Sep 12 04:51:59 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Sep 2019 06:51:59 +0200
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
Message-ID: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>

Hi,

very trivial fix.

jfrVirtualMemory.cpp uses UseLargePages and should hence include
globals.hpp (I ran into build problems when changing includes elsewhere).

Bug: https://bugs.openjdk.java.net/browse/JDK-8230888
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8230888-jfrvirtualmemory-cpp-should-include-globals-hpp/webrev.00/webrev/

Thanks, Thomas

From david.holmes at oracle.com  Thu Sep 12 05:29:48 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 15:29:48 +1000
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
In-Reply-To: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
References: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
Message-ID: <1e66afda-3d19-887c-679e-28eb15f48596@oracle.com>

Looks fine and trivial.

Thanks,
David

On 12/09/2019 2:51 pm, Thomas St?fe wrote:
> Hi,
> 
> very trivial fix.
> 
> jfrVirtualMemory.cpp uses UseLargePages and should hence include
> globals.hpp (I ran into build problems when changing includes elsewhere).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230888
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8230888-jfrvirtualmemory-cpp-should-include-globals-hpp/webrev.00/webrev/
> 
> Thanks, Thomas
> 

From thomas.stuefe at gmail.com  Thu Sep 12 03:36:10 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Sep 2019 05:36:10 +0200
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
In-Reply-To: <1e66afda-3d19-887c-679e-28eb15f48596@oracle.com>
References: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
 <1e66afda-3d19-887c-679e-28eb15f48596@oracle.com>
Message-ID: <CAA-vtUzz2KtU68rDY7prDVhcPQad8e6T_aBnCccXseLJ9z3_bA@mail.gmail.com>

Thanks David.

On Thu, Sep 12, 2019 at 7:29 AM David Holmes <david.holmes at oracle.com>
wrote:

> Looks fine and trivial.
>
> Thanks,
> David
>
> On 12/09/2019 2:51 pm, Thomas St?fe wrote:
> > Hi,
> >
> > very trivial fix.
> >
> > jfrVirtualMemory.cpp uses UseLargePages and should hence include
> > globals.hpp (I ran into build problems when changing includes elsewhere).
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8230888
> > webrev:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8230888-jfrvirtualmemory-cpp-should-include-globals-hpp/webrev.00/webrev/
> >
> > Thanks, Thomas
> >
>

From christoph.langer at sap.com  Thu Sep 12 07:23:31 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Sep 2019 07:23:31 +0000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
Message-ID: <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi David,

> test/lib/jdk/test/lib/Platform.java
> test/lib/jdk/test/lib/process/ProcessTools.java
> 
> in this code
> 
>                } catch (PrivilegedActionException e) {
> -                 @SuppressWarnings("unchecked")
>                    IOException t = (IOException) e.getException();
> 
> I take it these are unnecessary as these casts are not unchecked casts?

Yes, unchecked casts would rather occur with generics. This plain type cast will be checked at runtime. So, no javac or IDE warning if @SuppressWarnings("unchecked") is removed here.

> test/lib/jdk/test/lib/process/ProcessTools.java
> 
> -     @SuppressWarnings("overloads")
>        public static Process startProcess(String name,
>                                           ProcessBuilder processBuilder,
>                                           final Predicate<String>
> linePredicate)
> 
> Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?
I didn't find any reference either and the IDE says that this is an unknown annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.

> > Furthermore, when analyzing some test outputs lately, I got annoyed by
> stack traces like the following when using
> jdk.test.lib.process.StreamPumper. I think they are of no particular value and
> could be suppressed.
> >
> > java.io.IOException: Stream closed
> > at
> java.base/java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.
> java:169)
> > at
> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:335)
> > at
> java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
> > at
> java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:285
> )
> > at
> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
> > at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
> > at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:109)
> > at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja
> va:515)
> > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> > at java.base/java.lang.Thread.run(Thread.java:830)
> 
> Ok. Seems a bit crude, but then the StreamPumper code is crude - just
> running till it hits an exception, but an exception is the only way it
> will detect an async close of the stream.

Yep.

So, thanks for the review. Nightly test suite didn't show regressions. I guess I'll wait a bit until I push it if somebody still raises concerns.

Best regards
Christoph


From rwestrel at redhat.com  Thu Sep 12 07:56:30 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 12 Sep 2019 09:56:30 +0200
Subject: [14] RFR(XS): 8230762: Change MacroAssembler::debug32/64 to use
 fatal instead of assert
In-Reply-To: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
References: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
Message-ID: <878squkkwh.fsf@redhat.com>


> http://cr.openjdk.java.net/~chagedorn/8230762/webrev.00/

Looks good to me (I verified aarch64 does build).

Roland.

From christian.hagedorn at oracle.com  Thu Sep 12 08:07:39 2019
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Thu, 12 Sep 2019 10:07:39 +0200
Subject: [14] RFR(XS): 8230762: Change MacroAssembler::debug32/64 to use
 fatal instead of assert
In-Reply-To: <878squkkwh.fsf@redhat.com>
References: <bf01a8ac-8112-4906-2a02-c8d7932e37cb@oracle.com>
 <878squkkwh.fsf@redhat.com>
Message-ID: <72341262-3761-08d2-c219-b8492c36e4dd@oracle.com>

Hi Roland

Thanks for the review and the verification!

Best regards,
Christian

On 12.09.19 09:56, Roland Westrelin wrote:
> 
>> http://cr.openjdk.java.net/~chagedorn/8230762/webrev.00/
> 
> Looks good to me (I verified aarch64 does build).
> 
> Roland.
> 

From robbin.ehn at oracle.com  Thu Sep 12 08:36:51 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 12 Sep 2019 10:36:51 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <81d11a97-49f8-c61b-b31d-b6f6d1fd2e54@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <f52eaf30-f804-eb0a-7cc9-faf3dadddb0c@oracle.com>
 <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com>
 <acf6cf73-891b-bae6-7d28-3b041c894c4b@oracle.com>
 <1659e5d0-90c5-38f3-35ab-b55782c28935@oracle.com>
 <81d11a97-49f8-c61b-b31d-b6f6d1fd2e54@oracle.com>
Message-ID: <5dc3c46e-707d-1cdc-6b18-51d7815608e3@oracle.com>

Hi Dan, thanks for having a look.

On 9/11/19 12:19 AM, Daniel D. Daugherty wrote:
> src/hotspot/share/runtime/biasedLocking.cpp
>  ??? L729: void BiasedLocking::revoke_own_locks(Handle obj, TRAPS) {
>  ??????? Perhaps add:
>  ????????? assert(THREAD->is_Java_thread(), "must be called by a JavaThread");
>  ????????? JavaThread* thread = (JavaThread*)THREAD;
> 
>  ??????? and then switch uses of 'THREAD' for 'thread'. This way we
>  ??????? are not casting away a bad caller...

Fixed

> 
> src/hotspot/share/runtime/biasedLocking.hpp
>  ??? L193: ? // This should be called by a JavaThread to revoke the bias of an 
> owned object
>  ??????? Perhaps:
>  ??????????? // This must only be called by a JavaThread to revoke the bias of 
> an owned object.
> 

Fixed

> src/hotspot/share/runtime/deoptimization.cpp
>  ??? Moving the top part of Deoptimization::fetch_unroll_info_helper()
>  ??? made this hard to review, but I suspect leaving it in place would
>  ??? have been just as hard because of the refactor of code into
>  ??? eliminate_allocations() and eliminate_locks(). Did lots of
>  ??? scrolling of the frames windows and I think it looks correct...

There was one issue with ifdef which Patricio found.

> 
> src/hotspot/share/runtime/mutexLocker.cpp
>  ??? L236: ? def(CompiledMethod_lock????????? , PaddedMutex? , special-1,   
> true,? Monitor::_safepoint_check_never);
>  ??????? So CompiledMethod_lock is 'tty' + 1. Is that so that it ranks
>  ??????? lower than the Patching_lock? Any lock ranking issues expected
>  ??????? for the places you replaced Patching_lock with CompiledMethod_lock?
> 
>  ??????? I don't think you replaced all uses of Patching_lock, right?
>  ??????? (Sorry if I asked that before...)

Patching_lock is only used to mt-safe patch code.

> 
>  ??? old L251: ? def(OsrList_lock???????????????? , PaddedMutex? , leaf,        
> true,? Monitor::_safepoint_check_never);
>  ??????? So OsrList_lock was a 'leaf' and you've replaced its uses with
>  ??????? CompiledMethod_lock which is (special - 1). I'm assuming that
>  ??????? no lock ranking hiccups have been seen...

No problems.

> 
> src/hotspot/share/runtime/mutexLocker.hpp
>  ??? L35: extern Mutex*?? CompiledMethod_lock;???????????? // a lock used to 
> guard a compiled method
>  ??????? Should you also mention the OSR queues since CompiledMethod_lock
>  ??????? also replaced this:
> 
>  ??????? old L93: extern Mutex*?? OsrList_lock; // a lock used to serialize 
> access to OSR queues

Fixed

> 
> src/hotspot/share/runtime/sharedRuntime.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.hpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/tieredThresholdPolicy.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/vmOperations.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/vmOperations.hpp
>  ??? No comments (another VM_Op bites the dust...)
> 
> src/hotspot/share/services/dtraceAttacher.cpp
>  ??? No comments other than: Such a strange place to find the
>  ??? VM_DeoptimizeTheWorld VM_Op...
> 
> test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationAllTest.java
>  ??? Shouldn't there be an @bug 8226705 with the new test?
> 
>  ??? What tier does the new test execute in and have you verified
>  ??? that it passes on all Oracle platforms?

So this test was done for the original changeset.
This test don't reproduce that issue.
(it can in theory, but I have never seen it)
We had a WB test method which where not used by any test,
so I added a test which used, since this WB method would stress deopt.

> 
> You'll definitely want a review from a Compiler team member
> for this one. :-) Since there are Biased Locking changes,
> Patricio should also chime in here.
> 
> For testing, I'm assuming that the tests that failed due to
> 
>  ??? JDK-8221734 Deoptimize with handshakes
> 
> have been run on this REDO and that they pass.

The main issue is safepointing between revoking and expanding the stack, since a 
safepoint can rebais the lock (VM_BulkRevokeBias).

> 
> 
> Thumbs up! I don't need to see another webrev if you decide to
> make any changes due to my few comments above.

Thanks Dan!

/Robbin

> 
> Dan
> 
> 
>>
>> The problem is a nmethods state must never go backwards.
>> When the methods code is set to the compiled code it can be made not_entrant.
>> (it can be set to not_entrant before not having Compiled_lock)
>> When unlinking the methods code must point to the nmethod.
>>
>> If we set code before changing state, it can go backwards.
>> If we set state before setting code, we can't unlink it.
>>
>> This solution uses the new CompiledMethod_lock to synchronize code and state 
>> changes. (unloaded don't need the lock since it require a safepoint to happen)
>>
>> But this resulted in a circular lock issue with OsrList_lock.
>> Therefore OsrList_lock is removed, instead we use CompiledMethod_lock.
>>
>> After this patch it should be possible to remove Compile_lock from some paths. 
>> (Note that JVMCI is missing Compile_lock from several pathes, but fewer with 
>> this changeset)
>>
>> Also InterpreterRuntime::frequency_counter_overflow_inner seem to have the 
>> same bug as the reason for this redo: BiasedLocking::revoke(objects_to_revoke, 
>> thread);
>> The objects could have been rebaised by the time we return from it.
>> I think we should call the new 
>> BiasedLocking::revoke_own_locks(objects_to_revoke->at(i), thread); here also.
>>
>> Passes t1-5 twice and KS 60 min.
>>
>> @Erik I stayed with current is_in_use (not_installed + in_use), there were to 
>> many places and many of them needed an equivalent method if is_in_use was to 
>> be changed (to only in_use). I didn't see any issue with using the current 
>> definition.
>>
>> Thanks, Robbin
>>
>> On 8/29/19 4:35 PM, Erik ?sterlund wrote:
>>> Hi Robbin,
>>>
>>> On 2019-08-29 14:25, Robbin Ehn wrote:
>>>> Hi Erik, thanks for having a look.
>>>>
>>>> Just some short answers and questions.
>>>>
>>>> On 8/29/19 12:01 PM, Erik ?sterlund wrote:
>>>>> Hi Robbin,
>>>>>
>>>>> Glad to see this work making it back again. Last time this patch was 
>>>>> proposed, there were no guards against non-monotonic nmethod state 
>>>>> transitions. Today there are (since 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, if you 
>>>>> call make_not_entrant() on an nmethod that has racingly become zombie, it 
>>>>> is today impossible to resurrect that nmethod. Instead, make_not_entrant() 
>>>>> will return false.
>>>>
>>>> Great, I'll have a look.
>>>>
>>>>>
>>>>> In particular, I think that is what the following code in the patch is 
>>>>> guarding against (in codeCache.cpp):
>>>>>
>>>>> 1150 // Mark methods for deopt (if safe or possible).
>>>>> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() {
>>>>> 1152?? MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
>>>>> 1153?? CompiledMethodIterator 
>>>>> iter(CompiledMethodIterator::only_alive_and_not_unloading);
>>>>> 1154?? while(iter.next()) {
>>>>> 1155???? CompiledMethod* nm = iter.method();
>>>>> 1156???? if (!nm->method()->is_method_handle_intrinsic() &&
>>>>> 1157???????? !nm->is_not_installed() &&
>>>>> 1158???????? nm->is_in_use() &&
>>>>> 1159???????? !nm->is_native_method()) {
>>>>> 1160?????? // Intrinsics and native methods are never deopted. A method 
>>>>> that is
>>>>> 1161?????? // not installed yet or is not in use is not safe to deopt; the
>>>>> 1162?????? // is_in_use() check covers the not_entrant and not zombie cases.
>>>>> 1163?????? // Note: A not_entrant method can become a zombie at anytime if 
>>>>> it was
>>>>> 1164?????? // made not_entrant before the previous safepoint/handshake.
>>>>> 1165?????? nm->mark_for_deoptimization();
>>>>> 1166???? }
>>>>> 1167?? }
>>>>> 1168 }
>>>>>
>>>>> In fact, this code is also guarding against is_not_installed nmethods 
>>>>> (which was introduced as a new function). If we find that an nmethod is bad 
>>>>> and say it needs deoptimization, and that nmethod is just about to get 
>>>>> installed, it seems to me that skipping that nmethod and not making it not 
>>>>> entrant is really dangerous and will eventually lead to a crash. Because in 
>>>>> ciEnv.cpp we set_code to the about to be installed nmethod, and it will get 
>>>>> called without anything stopping the invalid code from being executed by 
>>>>> mutators, and it was being invalidated for a reason. So basically we really 
>>>>> do have to make these not entrant, or we will blow up.
>>>>>
>>>>> I guess the reason you needed this check is because make_in_use() doesn't 
>>>>> check what the current state is, causing monotonicity problems, making a 
>>>>> potentially already not entrant nmethod become in_use, eventually blowing 
>>>>> up asserts and probably the VM. Regrettably, make_in_use() still does that, 
>>>>> because I had no need for changing it to use nmethod::try_transition in 
>>>>> 8224674, nobody previously could find these nmethods. In retrospect, not 
>>>>> changing that was a bit silly. So if we just change make_in_use() to use 
>>>>> nmethod::try_transition instead, then you can remove the !is_not_installed 
>>>>> check... which I argue we have to do. The reason we never ran in to this 
>>>>> before is because we made the nmethods not entrant in a safepoint, and 
>>>>> between making an nmethod and making it in_use, there is no safepoint 
>>>>> check, so they were never observed in this state.
>>>>>
>>>>
>>>> Yes, thread A is creating a new method X, it have state not installed.
>>>> If we make method X not entrant, Thread A will flip it back to in_use, which 
>>>> bad
>>>> and we crash. mark_all_nmethods_for_deoptimization is a test method used in the
>>>> new jtreg test, which is the only use (I see dtrace have some hack to use 
>>>> it, it
>>>> can crash the vm).
>>>
>>> Exactly. However, what you are missing here is that this does not happen only 
>>> for the whitebox test, now that we do normal deopt with handshakes.
>>>
>>> Consider the following race.
>>>
>>> A compiler thread compiles a new nmethod. In this nmethod, it's assumed that 
>>> a certain invoke_virtual callsite is completely monomorphic, and the compiler 
>>> chooses to implement the callsite with a direct call, which is only valid 
>>> given its monomorphism. The compilation finishes, and at the very end of the 
>>> process, the code cache lock is grabbed, under which we allocate the new 
>>> nmethod, verify the assumptions made (which still hold), inject entries in 
>>> DependencyContexts so that if these assumptions change, we will deopt, and 
>>> then unlock the code cache lock. The nmethod is now still in the state 
>>> not_installed.
>>>
>>> What can happen now is that another thread loads a class that makes the 
>>> callsite potentially megamorphic. Deopt is triggered, walking the dependency 
>>> contexts under the CodeCache_lock, marking things that are now bad. In this 
>>> list we will find the newly compiled nmethod that has not been made in_use 
>>> yet. It is marked for deoptimization. Then the 
>>> Deoptimization::deoptimize_all_marked() function is called to make sure that 
>>> we 1) make all the marked nmethods not_entrant, and 2) arm the bad activation 
>>> records in the stack. Now the first step of the two grabs the code cache 
>>> lock, and walks the code cache. It finds our about to be installed nmethod, 
>>> and shoots make_not_entrant() at it, racing with the compiler thread calling 
>>> make_in_use() on it.
>>>
>>> This is why I advocate an approach where we simply make it safe to call 
>>> make_in_use() racing with make_not_entrant(), instead of trying to chase down 
>>> all possible scenarios in which this can happen. I can imagine a number of 
>>> others, now that deoptimization is being done with handshakes.
>>>
>>>>> ... and similarly here:
>>>>>
>>>>> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) {
>>>>> 1193?????? // only_alive_and_not_unloading() can return not_entrant nmethods.
>>>>> 1194?????? // A not_entrant method can become a zombie at anytime if it was
>>>>> 1195?????? // made not_entrant before the previous safepoint/handshake. The
>>>>> 1196?????? // is_in_use() check covers the not_entrant and not zombie cases
>>>>> 1197?????? // that have become true after the method was marked for deopt.
>>>>> 1198?????? nm->make_not_entrant();
>>>>> 1199???? }
>>>>>
>>>>> ... we now don't need the guard against is_in_use() here.
>>>>
>>>> Here we don't need that, but we don't need !nm->is_not_entrant() either, since
>>>> it would return false as you say!?
>>>
>>> Indeed. All state checks to see if it is even safe to call the state 
>>> transition function should be removed, as it should always be safe.
>>>
>>>> If we should have an early filter it think nm->is_in_use() is clearer than:
>>>> not not entrant ;) (since the not_installed is normally not seen here)
>>>
>>> The transitioning functions themselves already have early checks, so there 
>>> really is nothing to gain from checking if we should transition first and 
>>> then doing it.
>>>
>>>>>
>>>>> For what I propose to work out, we need to change nmethod::make_in_use to 
>>>>> use nmethod::try_transition, and AOTCompiledMethod::make_entrant() needs to 
>>>>> also return false when encountering a not_entrant nmethod, enforcing 
>>>>> monotonicity, instead of asserting about that. AOT methods may turn 
>>>>> not_in_use AOT methods to in_use, but not not_entrant to in_use. Once 
>>>>> not_entrant, an AOT methods should remain not entrant forever.
>>>>
>>>> The only time we see methods which are not installed should be methods that 
>>>> will
>>>> never be deoptimize (except when calling the test method
>>>> mark_all_nmethods_for_deoptimization), intrinsic and native.
>>>
>>> That's not right. It's visible to a bunch of deoptimizations.
>>>
>>>> And if I remember correctly make_in_use is called in a constructor which
>>>> requires extra error-handling. Construction would fail if try_transition 
>>>> failed.
>>>> The assumption about these 'never deopted' methods seem to be just that :)
>>>
>>> That is also not right. We grab the code cache lock, create the nmethod, 
>>> verify dependencies, install dependencies, drop the code cache lock, all 
>>> under not_installed. It's only after linking the Method to the code, that we 
>>> eventually set it to in_use. So it's visible for longer than you thought. And 
>>> it's visible to calls, a small instant before we change the state to 
>>> in_use(). That's what I claim isn't right. We don't want to be able to call 
>>> into these guys.
>>>
>>>>>
>>>>> So basically, these guards are for something that used to be racy and 
>>>>> dangerous due to the lack of guards inside of the state transitions, and 
>>>>> today that is completely harmless, as the proper guards are in the attempts 
>>>>> to change state. I would prefer to remove these guards, as it is confusing 
>>>>> to the reader that we are guarding against a problem that can't happen. So 
>>>>> I think you can remove the various checks for what state the nmethod is in, 
>>>>> the comments describing races, and just keep the checks if it's a method 
>>>>> handle intrinsic or native method.
>>>>
>>>> I'll revisit this. Was a few months since I did this.
>>>
>>> Okay!
>>>
>>>>>
>>>>> In deoptimize.cpp, the fetch_unroll_info_helper function has moved down, 
>>>>> making it difficult to review as shows the code delta as if everything 
>>>>> changed. So I can't see what actually changed there. :( Would you mind 
>>>>> moving that code back so the webrev shows what changed there?
>>>>
>>>> I have inserted two new static functions before fetch_unroll_info_helper,
>>>> since code from fetch_unroll_info_helper are in these functions diff do this.
>>>> They are static function they are best off before, and putting after them I
>>>> don't think would help the diff tool + I need fwd decl.
>>>> Suggestion?
>>>
>>> Okay, I will try to work out what the actual diff is manually.
>>>
>>> Thanks,
>>> /Erik
>>>
>>>> Thanks, Robbin
>>>>
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>> On 2019-08-28 11:57, Robbin Ehn wrote:
>>>>>> Hi, hotspot-dev was the intended list.
>>>>>>
>>>>>> Thanks, Robbin
>>>>>>
>>>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>>>> Hi all, please consider,
>>>>>>>
>>>>>>> To get away from the issues of us revoking in the handshake, but before 
>>>>>>> deopt
>>>>>>> the locks get re-biased before we hit deopt handler, we instead revoke in 
>>>>>>> deopt
>>>>>>> handler.
>>>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke 
>>>>>>> after
>>>>>>> that but before we start looking at the monitors, with a 
>>>>>>> NoSafepointVerifier.
>>>>>>>
>>>>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge 
>>>>>>> conflicts
>>>>>>> some pieces did not apply:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>>>>> So this is what was reviewed.
>>>>>>>
>>>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>>>
>>>>>>> Bug 8224795 fix is here:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>>>>
>>>>>>>
>>>>>>> After this we have the same functionally as the reverted change-set.
>>>>>>>
>>>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>>>>
>>>>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>>>>> Here is a refactoring of that code. (also removed a dead method in 
>>>>>>> biasedlocking):
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>>>
>>>>>>> And here is full:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>>>
>>>>>>> Also a full squashed patch file:
>>>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>>>
>>>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>>>>> running.
>>>>>>>
>>>>>>> Thanks, Robbin
>>>>>>>
>>>>>>>
> 

From per.liden at oracle.com  Thu Sep 12 08:48:10 2019
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Sep 2019 10:48:10 +0200
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
 <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
Message-ID: <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>


On 9/12/19 2:04 AM, Kim Barrett wrote:
>> On Sep 11, 2019, at 7:46 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> But as we are not actually enabling this as we don't turn on C++11, surely this still "looks good" enough? But we will have to look closer at things before turning it on? We may need to clarify our own rules for using thread-locals if we find there is a performance hit and we want to use the magic flag.
> 
> Part of the rationale for renaming to thread_local was that the
> transition to C++11 was trivial.  But apparently not so.
> 
> I really don't want to be tripping over this hidden performance hit
> when trying to throw the language standard switch.  (Assuming it's
> measurable, but we hit Thread::current() quite a bit, and ZGC has a
> bunch of thread-local variables pretty baked in and used fairly
> heavily I think.)  I do not want this little syntactic nicety to be an
> argument for not throwing that switch.
> 
> And in the long run, I'd prefer a different name if we're going to
> effectively have non-standard semantics (because of the usage
> restrictions required by that compiler flag).
> 

Ok, thanks for spotting the difference in gcc.

Given that they are said to be equivalent on windows and solaris, it 
sounds like we're already taking the dynamic init hit on those 
platforms. That's not necessarily a good reason to take that penalty on 
linux too, just an observation.

I looked closer at what the overhead is with gcc. For fundamental types 
and pointers (like our Thread::_thr_current), there's an extra 
test-and-branch sequence before the load.

	cmpq	$0, xxxx at GOTPCREL(%rip)
	je	done
	call	slow_path
done:

I've confirmed that -fno-extern-tls-init removes that test-and-branch.

I'm not super keep on spending too much time on investigating if this 
overhead is negligible or not. I also agree that messing with the 
thread_local semantics using -fno-extern-tls-init, or calling something 
thread_local that has non-standard semantics seems undesirable.

So, how about I dial this back a bit, and just rename THREAD_LOCAL_DECL 
to THREAD_LOCAL, just to make it a bit less clunky? That doesn't give us 
all the benefits I originally had in mind, but given the constraints we 
have here I don't see any better alternatives.

Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.2

/Per

From markus.gronlund at oracle.com  Thu Sep 12 09:48:39 2019
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 12 Sep 2019 02:48:39 -0700 (PDT)
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
In-Reply-To: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
References: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
Message-ID: <86cc9a9e-5644-4304-9f79-7e9bdcf77627@default>

Hi Thomas,

Looks good.

Thanks
Markus

-----Original Message-----
From: Thomas St?fe <thomas.stuefe at gmail.com> 
Sent: den 12 september 2019 06:52
To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp

Hi,

very trivial fix.

jfrVirtualMemory.cpp uses UseLargePages and should hence include globals.hpp (I ran into build problems when changing includes elsewhere).

Bug: https://bugs.openjdk.java.net/browse/JDK-8230888
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8230888-jfrvirtualmemory-cpp-should-include-globals-hpp/webrev.00/webrev/

Thanks, Thomas

From thomas.stuefe at gmail.com  Thu Sep 12 10:53:22 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Sep 2019 12:53:22 +0200
Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
In-Reply-To: <86cc9a9e-5644-4304-9f79-7e9bdcf77627@default>
References: <CAA-vtUyxZLaW3njS29+=kq7DcggwNRvg2MKtuJO-vdT44os+jA@mail.gmail.com>
 <86cc9a9e-5644-4304-9f79-7e9bdcf77627@default>
Message-ID: <CAA-vtUyw+rxQAYtwMv3d_9YdDzqHxfDu72v5O-4Jq+nm60SKDg@mail.gmail.com>

Thanks, Markus.

On Thu, Sep 12, 2019 at 11:49 AM Markus Gronlund <markus.gronlund at oracle.com>
wrote:

> Hi Thomas,
>
> Looks good.
>
> Thanks
> Markus
>
> -----Original Message-----
> From: Thomas St?fe <thomas.stuefe at gmail.com>
> Sent: den 12 september 2019 06:52
> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
> Subject: RFR(T): 8230888: jfrVirtualMemory.cpp should include globals.hpp
>
> Hi,
>
> very trivial fix.
>
> jfrVirtualMemory.cpp uses UseLargePages and should hence include
> globals.hpp (I ran into build problems when changing includes elsewhere).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8230888
> webrev:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8230888-jfrvirtualmemory-cpp-should-include-globals-hpp/webrev.00/webrev/
>
> Thanks, Thomas
>

From david.holmes at oracle.com  Thu Sep 12 10:53:36 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Sep 2019 20:53:36 +1000
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
 <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
 <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
Message-ID: <f83540bc-e9e2-9fd3-a9fb-ad9250240eaa@oracle.com>

Hi Per,

On 12/09/2019 6:48 pm, Per Liden wrote:
> 
> On 9/12/19 2:04 AM, Kim Barrett wrote:
>>> On Sep 11, 2019, at 7:46 PM, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> But as we are not actually enabling this as we don't turn on C++11, 
>>> surely this still "looks good" enough? But we will have to look 
>>> closer at things before turning it on? We may need to clarify our own 
>>> rules for using thread-locals if we find there is a performance hit 
>>> and we want to use the magic flag.
>>
>> Part of the rationale for renaming to thread_local was that the
>> transition to C++11 was trivial.? But apparently not so.
>>
>> I really don't want to be tripping over this hidden performance hit
>> when trying to throw the language standard switch.? (Assuming it's
>> measurable, but we hit Thread::current() quite a bit, and ZGC has a
>> bunch of thread-local variables pretty baked in and used fairly
>> heavily I think.)? I do not want this little syntactic nicety to be an
>> argument for not throwing that switch.
>>
>> And in the long run, I'd prefer a different name if we're going to
>> effectively have non-standard semantics (because of the usage
>> restrictions required by that compiler flag).
>>
> 
> Ok, thanks for spotting the difference in gcc.
> 
> Given that they are said to be equivalent on windows and solaris, it 
> sounds like we're already taking the dynamic init hit on those 
> platforms. That's not necessarily a good reason to take that penalty on 
> linux too, just an observation.

Seems more like an assumption :) Who said there is any "dynamic init 
hit" on those platforms?

> I looked closer at what the overhead is with gcc. For fundamental types 
> and pointers (like our Thread::_thr_current), there's an extra 
> test-and-branch sequence before the load.
> 
>  ????cmpq??? $0, xxxx at GOTPCREL(%rip)
>  ????je??? done
>  ????call??? slow_path
> done:
> 
> I've confirmed that -fno-extern-tls-init removes that test-and-branch.
> 
> I'm not super keep on spending too much time on investigating if this 
> overhead is negligible or not. I also agree that messing with the 
> thread_local semantics using -fno-extern-tls-init, or calling something 
> thread_local that has non-standard semantics seems undesirable.
> 
> So, how about I dial this back a bit, and just rename THREAD_LOCAL_DECL 
> to THREAD_LOCAL, just to make it a bit less clunky? That doesn't give us 
> all the benefits I originally had in mind, but given the constraints we 
> have here I don't see any better alternatives.
> 
> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.2

The rename to drop _DECL is fine and trivial.

Removing the USE_LIBRARY_BASED_TLS_ONLY guard makes it harder to test 
with compiler-thread-local disabled. But not drastically so.

So I'm okay with this minor change.

Thanks,
David

> /Per

From robbin.ehn at oracle.com  Thu Sep 12 11:21:25 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 12 Sep 2019 13:21:25 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
Message-ID: <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>

Hi, here is v3, addressing Patricio's and Dan's review comments.

Inc:
http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/

Full:
http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/

Passed t1-5, doing some more testing also.

Thanks, Robbin

On 8/28/19 11:57 AM, Robbin Ehn wrote:
> Hi, hotspot-dev was the intended list.
> 
> Thanks, Robbin
> 
> On 2019-08-28 09:30, Robbin Ehn wrote:
>> Hi all, please consider,
>>
>> To get away from the issues of us revoking in the handshake, but before deopt
>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>> handler.
>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>
>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>> some pieces did not apply:
>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>> So this is what was reviewed.
>>
>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>
>> Bug 8224795 fix is here:
>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>
>>
>> After this we have the same functionally as the reverted change-set.
>>
>> Here is the changes for doing the revoke in deopt handler instead:
>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>
>> This code was messy adding the deopt revocation in 3 places made it worse.
>> Here is a refactoring of that code. (also removed a dead method in 
>> biasedlocking):
>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>
>> And here is full:
>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>
>> Also a full squashed patch file:
>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>
>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>> running.
>>
>> Thanks, Robbin
>>
>>

From per.liden at oracle.com  Thu Sep 12 11:42:43 2019
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Sep 2019 13:42:43 +0200
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <f83540bc-e9e2-9fd3-a9fb-ad9250240eaa@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
 <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
 <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
 <f83540bc-e9e2-9fd3-a9fb-ad9250240eaa@oracle.com>
Message-ID: <2e7e39ab-698f-a8ea-a892-9b9fff74ef60@oracle.com>

On 9/12/19 12:53 PM, David Holmes wrote:
[...]>> So, how about I dial this back a bit, and just rename
>> THREAD_LOCAL_DECL to THREAD_LOCAL, just to make it a bit less clunky? 
>> That doesn't give us all the benefits I originally had in mind, but 
>> given the constraints we have here I don't see any better alternatives.
>>
>> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.2
> 
> The rename to drop _DECL is fine and trivial.
> 
> Removing the USE_LIBRARY_BASED_TLS_ONLY guard makes it harder to test 
> with compiler-thread-local disabled. But not drastically so.
> 
> So I'm okay with this minor change.

Thanks David!

/Per

From lois.foltan at oracle.com  Thu Sep 12 15:40:40 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 12 Sep 2019 11:40:40 -0400
Subject: RFR (L) JDK-8230505: Replace JVM type comparisons to T_OBJECT and
 T_ARRAY with call to is_reference_type
In-Reply-To: <355f0f87-c158-f730-2061-fbdfb94ca527@oracle.com>
References: <6731f56d-7bbe-efe5-e4e3-4c0da284fd93@oracle.com>
 <355f0f87-c158-f730-2061-fbdfb94ca527@oracle.com>
Message-ID: <8f06566f-6260-01e5-889b-bb814e62eadb@oracle.com>

On 9/11/2019 4:38 PM, dean.long at oracle.com wrote:
> This makes me wish we could call BasicType::is_reference_type() :-)
>
> I was going to suggest replacing the small number of 
> "is_reference_type(result->get_type()))" with 
> "result->is_reference_type()", but maybe it's not worth adding a 
> helper method for so few uses.? It does look more "OO" however.

Thanks Dean for taking a look at the webrev.? I am leaving the change as 
is.? As you mention a helper method might not be worth adding in this case.

Lois

>
> dl
>
> On 9/11/19 8:29 AM, Lois Foltan wrote:
>> Please review the following change to call is_reference_type() when 
>> checking if a type is a T_OBJECT or a T_ARRAY.
>>
>> open webrev at: 
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8230505.0/webrev/index.html
>> bug link: https://bugs.openjdk.java.net/browse/JDK-8230505
>>
>> Builds: all tier1 builds, did build with Shenandoah GC, and Solaris 
>> builds
>> Testing: hs-tier1-4 & jdktier1-2 (all platforms), hs-tier5-8 (linux-x64)
>>
>> Thanks,
>> Lois
>>
>>
>


From kim.barrett at oracle.com  Thu Sep 12 17:21:08 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 12 Sep 2019 13:21:08 -0400
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
 <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
 <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
Message-ID: <C21B4775-9DFB-46EC-AC1E-DF6F35074F14@oracle.com>

> On Sep 12, 2019, at 4:48 AM, Per Liden <per.liden at oracle.com> wrote:
> So, how about I dial this back a bit, and just rename THREAD_LOCAL_DECL to THREAD_LOCAL, just to make it a bit less clunky? That doesn't give us all the benefits I originally had in mind, but given the constraints we have here I don't see any better alternatives.
> 
> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.2
> 
> /Per

That looks good.

Too bad the earlier version didn?t work out; it looked nice.


From per.liden at oracle.com  Thu Sep 12 18:48:02 2019
From: per.liden at oracle.com (Per Liden)
Date: Thu, 12 Sep 2019 20:48:02 +0200
Subject: RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local
In-Reply-To: <C21B4775-9DFB-46EC-AC1E-DF6F35074F14@oracle.com>
References: <d03cb588-d933-b420-8fbb-3f0a51d5cc73@oracle.com>
 <D1E793FA-FEC3-46F1-A187-4C2627C6983B@oracle.com>
 <4DCAEFAB-C402-4D08-A26D-DEADE3EE75F3@oracle.com>
 <f233b02a-de9d-26f5-8415-84bf38df3f81@oracle.com>
 <734e5cd3-55c8-4e37-2e08-a0cc8de526a8@oracle.com>
 <BCBE42AC-19CF-45E9-9C16-E591EF2A3E73@oracle.com>
 <0d73168d-5cff-984b-d107-acec914545bc@oracle.com>
 <94B4EF4E-D67B-4117-8E87-C0E930CE7724@oracle.com>
 <c0d5630d-90af-8b58-c1d7-0818364eae26@oracle.com>
 <C21B4775-9DFB-46EC-AC1E-DF6F35074F14@oracle.com>
Message-ID: <6e9ae20d-3a27-5ce5-9182-b03626cac67e@oracle.com>

On 9/12/19 7:21 PM, Kim Barrett wrote:
>> On Sep 12, 2019, at 4:48 AM, Per Liden <per.liden at oracle.com> wrote:
>> So, how about I dial this back a bit, and just rename THREAD_LOCAL_DECL to THREAD_LOCAL, just to make it a bit less clunky? That doesn't give us all the benefits I originally had in mind, but given the constraints we have here I don't see any better alternatives.
>>
>> Updated webrev: http://cr.openjdk.java.net/~pliden/8230877/webrev.2
>>
>> /Per
> 
> That looks good.
> 
> Too bad the earlier version didn?t work out; it looked nice.
> 

Thanks for reviewing Kim!

Btw, I'll adjust the bug title and description before pushing.

/Per

From dean.long at oracle.com  Thu Sep 12 22:54:31 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Thu, 12 Sep 2019 15:54:31 -0700
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
Message-ID: <d6835806-f6e2-43de-2435-0e20c6fb857f@oracle.com>

Hi Robbin.

I like the new CompiledMethod_lock.? I had some concerns with 8224674 
about races between make_not_entrant and make_unloaded, so I was half 
expecting CompiledMethod_lock to be used at a higher level than 
Patching_lock and protect the whole call to make_not_entrant and 
make_unloaded.? Does make_unloaded need to use CompiledMethod_lock at all?

dl

PS - Erik said he would file a RFE to refactor/cleanup make_not_entrant 
and make_unloaded, but I can't find it.

On 9/12/19 4:21 AM, Robbin Ehn wrote:
> Hi, here is v3, addressing Patricio's and Dan's review comments.
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>
> Passed t1-5, doing some more testing also.
>
> Thanks, Robbin
>
> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>> Hi, hotspot-dev was the intended list.
>>
>> Thanks, Robbin
>>
>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>> Hi all, please consider,
>>>
>>> To get away from the issues of us revoking in the handshake, but 
>>> before deopt
>>> the locks get re-biased before we hit deopt handler, we instead 
>>> revoke in deopt
>>> handler.
>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>> revoke after
>>> that but before we start looking at the monitors, with a 
>>> NoSafepointVerifier.
>>>
>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>> merge conflicts
>>> some pieces did not apply:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>
>>> So this is what was reviewed.
>>>
>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>
>>> Bug 8224795 fix is here:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>
>>>
>>> After this we have the same functionally as the reverted change-set.
>>>
>>> Here is the changes for doing the revoke in deopt handler instead:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>
>>>
>>> This code was messy adding the deopt revocation in 3 places made it 
>>> worse.
>>> Here is a refactoring of that code. (also removed a dead method in 
>>> biasedlocking):
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>
>>> And here is full:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>
>>> Also a full squashed patch file:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>
>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX 
>>> still
>>> running.
>>>
>>> Thanks, Robbin
>>>
>>>


From brent.christian at oracle.com  Thu Sep 12 23:02:53 2019
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 12 Sep 2019 16:02:53 -0700
Subject: RFR 8230937 : Update bugid in ProblemList for
 vmTestbase/nsk/jdb/eval/eval001/eval001.java
Message-ID: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com>

Hi,

 From the bug report:

"The ProblemList indicates that 
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
JDK-8212117. That bug has been fixed, but this test still fails. That 
line in the ProblemList should instead use 8221503."

The change is:

diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt	Thu Sep 12 09:59:19 2019 -0700
+++ b/test/hotspot/jtreg/ProblemList.txt	Thu Sep 12 15:52:07 2019 -0700
@@ -167,7 +167,7 @@
 
vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
8065773 generic-all

-vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
+vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all

  vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
generic-all

Thanks,
-Brent

From mandy.chung at oracle.com  Fri Sep 13 00:30:19 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Sep 2019 17:30:19 -0700
Subject: RFR 8230937 : Update bugid in ProblemList for
 vmTestbase/nsk/jdb/eval/eval001/eval001.java
In-Reply-To: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com>
References: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com>
Message-ID: <bd19ebe9-f024-a91c-d770-9d5ed4baf514@oracle.com>

+1
Mandy

On 9/12/19 4:02 PM, Brent Christian wrote:
> Hi,
>
> From the bug report:
>
> "The ProblemList indicates that 
> vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
> JDK-8212117. That bug has been fixed, but this test still fails. That 
> line in the ProblemList should instead use 8221503."
>
> The change is:
>
> diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 09:59:19 2019 
> -0700
> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 15:52:07 2019 
> -0700
> @@ -167,7 +167,7 @@
>
> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
> 8065773 generic-all
>
> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all
>
> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
> generic-all
>
> Thanks,
> -Brent


From david.holmes at oracle.com  Fri Sep 13 01:04:50 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2019 11:04:50 +1000
Subject: RFR 8230937 : Update bugid in ProblemList for
 vmTestbase/nsk/jdb/eval/eval001/eval001.java
In-Reply-To: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com>
References: <17152ac6-6902-f56e-a187-0ce0d4662391@oracle.com>
Message-ID: <1179284f-d71e-1e89-b243-635e0fc152cd@oracle.com>

Looks good.

Thanks for updating.

David

On 13/09/2019 9:02 am, Brent Christian wrote:
> Hi,
> 
>  From the bug report:
> 
> "The ProblemList indicates that 
> vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to 
> JDK-8212117. That bug has been fixed, but this test still fails. That 
> line in the ProblemList should instead use 8221503."
> 
> The change is:
> 
> diff -r 85e1de070bef test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 09:59:19 2019 -0700
> +++ b/test/hotspot/jtreg/ProblemList.txt??? Thu Sep 12 15:52:07 2019 -0700
> @@ -167,7 +167,7 @@
> 
> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 
> 8065773 generic-all
> 
> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all
> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all
> 
>  ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 
> generic-all
> 
> Thanks,
> -Brent

From david.holmes at oracle.com  Fri Sep 13 05:56:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2019 15:56:41 +1000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
 <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>

Hi Christoph,

On 12/09/2019 5:23 pm, Langer, Christoph wrote:
> Hi David,
> 
>> test/lib/jdk/test/lib/Platform.java
>> test/lib/jdk/test/lib/process/ProcessTools.java
>>
>> in this code
>>
>>                 } catch (PrivilegedActionException e) {
>> -                 @SuppressWarnings("unchecked")
>>                     IOException t = (IOException) e.getException();
>>
>> I take it these are unnecessary as these casts are not unchecked casts?
> 
> Yes, unchecked casts would rather occur with generics. This plain type cast will be checked at runtime. So, no javac or IDE warning if @SuppressWarnings("unchecked") is removed here.
> 
>> test/lib/jdk/test/lib/process/ProcessTools.java
>>
>> -     @SuppressWarnings("overloads")
>>         public static Process startProcess(String name,
>>                                            ProcessBuilder processBuilder,
>>                                            final Predicate<String>
>> linePredicate)
>>
>> Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?
> I didn't find any reference either and the IDE says that this is an unknown annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.

Not it is a valid warning. Try compiling with -Xlint:all without the 
warning suppressed:

----------System.err:(19/1295)----------
/scratch/users/daholme/jdk-dev2/open/test/lib/jdk/test/lib/process/ProcessTools.java:91: 
warning: [overloads] 
startProcess(String,ProcessBuilder,Consumer<String>) in ProcessTools is 
potentially ambiguous with 
startProcess(String,ProcessBuilder,Predicate<String>) in ProcessTools
     public static Process startProcess(String name,
                           ^
Thanks,
David
-----

>>> Furthermore, when analyzing some test outputs lately, I got annoyed by
>> stack traces like the following when using
>> jdk.test.lib.process.StreamPumper. I think they are of no particular value and
>> could be suppressed.
>>>
>>> java.io.IOException: Stream closed
>>> at
>> java.base/java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.
>> java:169)
>>> at
>> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:335)
>>> at
>> java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
>>> at
>> java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:285
>> )
>>> at
>> java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
>>> at java.base/java.io.FilterInputStream.read(FilterInputStream.java:107)
>>> at jdk.test.lib.process.StreamPumper.run(StreamPumper.java:109)
>>> at
>> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja
>> va:515)
>>> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>>> at java.base/java.lang.Thread.run(Thread.java:830)
>>
>> Ok. Seems a bit crude, but then the StreamPumper code is crude - just
>> running till it hits an exception, but an exception is the only way it
>> will detect an async close of the stream.
> 
> Yep.
> 
> So, thanks for the review. Nightly test suite didn't show regressions. I guess I'll wait a bit until I push it if somebody still raises concerns.
> 
> Best regards
> Christoph
> 

From robbin.ehn at oracle.com  Fri Sep 13 06:45:28 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 13 Sep 2019 08:45:28 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <d6835806-f6e2-43de-2435-0e20c6fb857f@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
 <d6835806-f6e2-43de-2435-0e20c6fb857f@oracle.com>
Message-ID: <8332acb3-a093-81a4-ad0f-c670895cdfa6@oracle.com>

Hi Dean,

unloaded happens in a safepoint (or with zgc after) when it is safe to unload. 
Since we do not safepoint when creating a nmethod we know that methods marked 
for unloading must have been created before that safepoint.
And if we can unload a method it must not be on any stack.
Sweeper can go directly from unloaded to zombie.

Thanks for having a look!

If Erik cleans this up a bit, that would be nice :)

/Robbin

On 9/13/19 12:54 AM, dean.long at oracle.com wrote:
> Hi Robbin.
> 
> I like the new CompiledMethod_lock.? I had some concerns with 8224674 about 
> races between make_not_entrant and make_unloaded, so I was half expecting 
> CompiledMethod_lock to be used at a higher level than Patching_lock and protect 
> the whole call to make_not_entrant and make_unloaded.? Does make_unloaded need 
> to use CompiledMethod_lock at all?
> 
> dl
> 
> PS - Erik said he would file a RFE to refactor/cleanup make_not_entrant and 
> make_unloaded, but I can't find it.
> 
> On 9/12/19 4:21 AM, Robbin Ehn wrote:
>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>
>> Passed t1-5, doing some more testing also.
>>
>> Thanks, Robbin
>>
>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>> Hi, hotspot-dev was the intended list.
>>>
>>> Thanks, Robbin
>>>
>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>> Hi all, please consider,
>>>>
>>>> To get away from the issues of us revoking in the handshake, but before deopt
>>>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>>>> handler.
>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>>
>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>>>> some pieces did not apply:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>> So this is what was reviewed.
>>>>
>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>
>>>> Bug 8224795 fix is here:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>
>>>>
>>>> After this we have the same functionally as the reverted change-set.
>>>>
>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>
>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>> Here is a refactoring of that code. (also removed a dead method in 
>>>> biasedlocking):
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>
>>>> And here is full:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>
>>>> Also a full squashed patch file:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>
>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>> running.
>>>>
>>>> Thanks, Robbin
>>>>
>>>>
> 

From christoph.langer at sap.com  Fri Sep 13 08:04:39 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Sep 2019 08:04:39 +0000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
 <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>
Message-ID: <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi David,

> >> test/lib/jdk/test/lib/process/ProcessTools.java
> >>
> >> -     @SuppressWarnings("overloads")
> >>         public static Process startProcess(String name,
> >>                                            ProcessBuilder processBuilder,
> >>                                            final Predicate<String>
> >> linePredicate)
> >>
> >> Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?
> > I didn't find any reference either and the IDE says that this is an unknown
> annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.
> 
> Not it is a valid warning. Try compiling with -Xlint:all without the
> warning suppressed:
> 
> ----------System.err:(19/1295)----------
> /scratch/users/daholme/jdk-
> dev2/open/test/lib/jdk/test/lib/process/ProcessTools.java:91:
> warning: [overloads]
> startProcess(String,ProcessBuilder,Consumer<String>) in ProcessTools is
> potentially ambiguous with
> startProcess(String,ProcessBuilder,Predicate<String>) in ProcessTools
>      public static Process startProcess(String name,
>                            ^

Thanks for taking a closer look here and enlightening me.

@SuppressWarnings("overloads") is supported by javac but not by my Eclipse IDE. One can list supported @SuppressWarnings types with javac -X. You'll get:
overloads            Warn about issues regarding method overloads.

So I now understand what the warning means and why @SuppressWarnings("overloads") is required here. I've also configured my Eclipse to ignore this unknown annotation.

New webrev, keeping @SuppressWarnings("overloads"): http://cr.openjdk.java.net/~clanger/webrevs/8230854.1/

Best regards
Christoph


From david.holmes at oracle.com  Fri Sep 13 09:12:14 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2019 19:12:14 +1000
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
Message-ID: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>

webrev: http://cr.openjdk.java.net/~dholmes/8230424/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8230424

The next instalment of the interruption logic refactoring.

Summary of changes:
- the windows-specific actions in os:interrupt and os::is_interrupted 
are pushed down into the windows-specific osThread code. This all 
relates to the only-used-by-the-JDK _interrupt_event.
- the POSIX variant of os::interrupt and os::is_interrupted is inlined 
as platform-independent code in the Thread versions and those versions 
are themselves moved to JavaThread as instance methods.
- minor cleanups to the logic of interrupt() as we can never have NULL 
events as we are always guaranteed to be operating on a live thread.
- All call sites adjusted as needed.

One minor wart in this refactor is that on Windows we will execute an 
OrderAccess::release() after setting the interrupt state in the platform 
code, and then execute an additional fence() in the shared code. I don't 
think this is worth trying to "fix" - and hopefully if we can get rid of 
the Windows _interrupt_event this will all go away.

If you are wondering why Windows used OrderAccess::release while POSIX 
used OrderAccess::fence, I have no idea, and I do not intend to change 
either of them. The only safe change would be to use fence() in both 
cases, which just makes the Windows wart worse - and unnecessarily so as 
we have seen no bugs using the existing release().

Testing:
  - hotspot runtime
  - Tiers 1-3

Thanks,
David

From david.holmes at oracle.com  Fri Sep 13 09:17:08 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Sep 2019 19:17:08 +1000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
 <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>
 <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <7f7dd0c7-a36f-9608-81a7-56a298e17a11@oracle.com>

Hi Christoph,

Update looks good.

I assume you've tested by building with javac (and Eclipse!) with 
-Xlint:all ? :)

Thanks,
David

On 13/09/2019 6:04 pm, Langer, Christoph wrote:
> Hi David,
> 
>>>> test/lib/jdk/test/lib/process/ProcessTools.java
>>>>
>>>> -     @SuppressWarnings("overloads")
>>>>          public static Process startProcess(String name,
>>>>                                             ProcessBuilder processBuilder,
>>>>                                             final Predicate<String>
>>>> linePredicate)
>>>>
>>>> Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?
>>> I didn't find any reference either and the IDE says that this is an unknown
>> annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.
>>
>> Not it is a valid warning. Try compiling with -Xlint:all without the
>> warning suppressed:
>>
>> ----------System.err:(19/1295)----------
>> /scratch/users/daholme/jdk-
>> dev2/open/test/lib/jdk/test/lib/process/ProcessTools.java:91:
>> warning: [overloads]
>> startProcess(String,ProcessBuilder,Consumer<String>) in ProcessTools is
>> potentially ambiguous with
>> startProcess(String,ProcessBuilder,Predicate<String>) in ProcessTools
>>       public static Process startProcess(String name,
>>                             ^
> 
> Thanks for taking a closer look here and enlightening me.
> 
> @SuppressWarnings("overloads") is supported by javac but not by my Eclipse IDE. One can list supported @SuppressWarnings types with javac -X. You'll get:
> overloads            Warn about issues regarding method overloads.
> 
> So I now understand what the warning means and why @SuppressWarnings("overloads") is required here. I've also configured my Eclipse to ignore this unknown annotation.
> 
> New webrev, keeping @SuppressWarnings("overloads"): http://cr.openjdk.java.net/~clanger/webrevs/8230854.1/
> 
> Best regards
> Christoph
> 

From fujie at loongson.cn  Sat Sep 14 09:00:36 2019
From: fujie at loongson.cn (Jie Fu)
Date: Sat, 14 Sep 2019 17:00:36 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
Message-ID: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>

Hi all,

JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231024
Webrev: http://cr.openjdk.java.net/~jiefu/8231024/webrev.00/

*Background*
When I was running a jtreg test with
------------------------------------
make test 
TEST="test/jdk/java/lang/invoke/TestCatchExceptionWithVarargs.java" 
CONF=fast
------------------------------------
I got some VM warnings which just told me to increase O_BUFLEN in 
ostream.hpp.
But the debug info didn't tell us the proper value of O_BUFLEN needed by 
the output.

It might be better to dump the required value of O_BUFLEN.

*Fix*

- Before the patch
------------------------------------
[2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
...
------------------------------------

- After the patch
------------------------------------
[2019-09-14 16:19:09,478] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp: at least 2013 is required -- 
output truncated
[2019-09-14 16:19:09,482] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp: at least 2031 is required -- 
output truncated
[2019-09-14 16:19:09,488] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp: at least 2049 is required -- 
output truncated
------------------------------------

Could you please review it?

Thanks a lot.
Best regards,
Jie



From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 14 20:57:39 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 14 Sep 2019 22:57:39 +0200
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
Message-ID: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>

Hi,

I was advised by Oracle's Fairoz Matte to contact this list.

I am seeing a Java process use 100% of one CPU core continuously, but no
Java threads are runnable (as evidenced by internal thread sampling as well
as VisualVM).

Whenever it occurs, the problem does not seem to go away until the Java VM
exits.

I think I am using a single native library (OSHI), the rest is pure Java.

Older versions of the JDK have exhibited the same problem, but most
interestingly, the bug is happening right now on a Linux machine
(Peppermint 7 I think) with OpenJDK 13 EA Build 31.

I can perform any test on this machine that you instruct me to.

Please advise,
Stefan

-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From ioi.lam at oracle.com  Sat Sep 14 21:40:53 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sat, 14 Sep 2019 14:40:53 -0700
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
Message-ID: <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>

Hi Stefan,

Is it possible for you to create a test case that reproduce this problem?

If not, try running the program inside a Linux terminal, and when the 
CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the 
states of all the threads that the JVM knows about. It might give you 
some idea what's happening.

An alternative is to run your program inside gdb,

$ gdb jdk13/bin/java
(gdb) handle SIGSEGV noprint
(gdb) handle SIGSEGV nostop
(gdb) set print thread-events off
(gdb) set height 0
(gdb) run -cp myapp.jar App

(When the program enters the 100% CPU state, type Ctrl-C)

^C
Thread 1 "java" received signal SIGINT, Interrupt.
0x00007ffff779798d in pthread_join (threadid=140737353910016, 
thread_return=0x7fffffff8508) at pthread_join.c:90
90??? pthread_join.c: No such file or directory.
(gdb) thread apply all where

This will list all stacks of all the threads, including ones that the 
JVM may not be aware of. This should tell you who is spinning the CPU.

Thanks
- Ioi




On 9/14/19 1:57 PM, Stefan Reich wrote:
> Hi,
>
> I was advised by Oracle's Fairoz Matte to contact this list.
>
> I am seeing a Java process use 100% of one CPU core continuously, but no
> Java threads are runnable (as evidenced by internal thread sampling as well
> as VisualVM).
>
> Whenever it occurs, the problem does not seem to go away until the Java VM
> exits.
>
> I think I am using a single native library (OSHI), the rest is pure Java.
>
> Older versions of the JDK have exhibited the same problem, but most
> interestingly, the bug is happening right now on a Linux machine
> (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>
> I can perform any test on this machine that you instruct me to.
>
> Please advise,
> Stefan
>


From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 14 21:49:47 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 14 Sep 2019 23:49:47 +0200
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
Message-ID: <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>

Hi,

thanks for your answer. Unfortunately, I still don't know what triggers the
"bad" state, so no test case... It happens randomly, but as I said, once it
does, it doesn't go away anymore. (Still happening right now.)

Would the result from Thread.getAllStackTraces() help? I attached that to
this email.

Many greetings,
Stefan


On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:

> Hi Stefan,
>
> Is it possible for you to create a test case that reproduce this problem?
>
> If not, try running the program inside a Linux terminal, and when the
> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
> states of all the threads that the JVM knows about. It might give you
> some idea what's happening.
>
> An alternative is to run your program inside gdb,
>
> $ gdb jdk13/bin/java
> (gdb) handle SIGSEGV noprint
> (gdb) handle SIGSEGV nostop
> (gdb) set print thread-events off
> (gdb) set height 0
> (gdb) run -cp myapp.jar App
>
> (When the program enters the 100% CPU state, type Ctrl-C)
>
> ^C
> Thread 1 "java" received signal SIGINT, Interrupt.
> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
> thread_return=0x7fffffff8508) at pthread_join.c:90
> 90    pthread_join.c: No such file or directory.
> (gdb) thread apply all where
>
> This will list all stacks of all the threads, including ones that the
> JVM may not be aware of. This should tell you who is spinning the CPU.
>
> Thanks
> - Ioi
>
>
>
>
> On 9/14/19 1:57 PM, Stefan Reich wrote:
> > Hi,
> >
> > I was advised by Oracle's Fairoz Matte to contact this list.
> >
> > I am seeing a Java process use 100% of one CPU core continuously, but no
> > Java threads are runnable (as evidenced by internal thread sampling as
> well
> > as VisualVM).
> >
> > Whenever it occurs, the problem does not seem to go away until the Java
> VM
> > exits.
> >
> > I think I am using a single native library (OSHI), the rest is pure Java.
> >
> > Older versions of the JDK have exhibited the same problem, but most
> > interestingly, the bug is happening right now on a Linux machine
> > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
> >
> > I can perform any test on this machine that you instruct me to.
> >
> > Please advise,
> > Stefan
> >
>
>

-- 
Stefan Reich
BotCompany.de // Java-based operating systems
-------------- next part --------------

75 threads
Thread[A timer by #1019239,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[StdErr Piper,5,main]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  app//x30.sleep(x30.java:2550)
  app//x30.run(x30.java:1907)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1018866: updateMe();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Common-Cleaner,8,InnocuousThreadGroup]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155)
  java.base at 13-ea/jdk.internal.ref.CleanerImpl.run(CleanerImpl.java:148)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)
  java.base at 13-ea/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:134)

Thread[Displayer,6,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.base at 13-ea/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417)
  java.desktop at 13-ea/sun.awt.X11.InfoWindow$Balloon$Displayer.run(InfoWindow.java:493)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1016872: update,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1019696: if (!licensed() || dm_shuttingDown()) return;
      if (hasBot("St...,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1016578,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1019034: updateMe();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Timer-27423,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1023851: check();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A thread by #1017551,6,main]
  java.base at 13-ea/java.lang.Thread.dumpThreads(Native Method)
  java.base at 13-ea/java.lang.Thread.getAllStackTraces(Thread.java:1649)
  main.renderAllThreadsWithStackTraces(main.java:40)
  main.calc(main.java:28)
  java.base at 13-ea/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  java.base at 13-ea/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  java.base at 13-ea/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  java.base at 13-ea/java.lang.reflect.Method.invoke(Method.java:567)
  main.invokeMethod(main.java:1693)
  main.call_withVarargs(main.java:703)
  main.call(main.java:268)
  main.callCalc(main.java:5238)
  main.evalJava_myProgramID_main_2(main.java:3952)
  main.dm_evalJava_withModule(main.java:2629)
  main.dm_javaEval(main.java:1349)
  main.dm_javaEvalModule_doIt(main.java:656)
  main$JavaEval.evalIt(main.java:216)
  main$JavaEval$1.run(main.java:145)
  main$46.run(main.java:3459)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1024932: printDeadlocksAndSolve();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1025132,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Timer-27434,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.Object.wait(Object.java:326)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:527)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Java CPU Monitor,5,main]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  main.sleep(main.java:504)
  main$2.run(main.java:76)
  main$17.run(main.java:2790)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1022569: actualUpdate();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1020927: actualUpdate();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Timer-1,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1020622: saveIfChanged();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Connect,5,main]
  java.base at 13-ea/sun.nio.ch.Net.poll(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:182)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:286)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
  java.base at 13-ea/java.net.Socket$SocketInputStream.read(Socket.java:919)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:297)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
  java.base at 13-ea/java.io.InputStreamReader.read(InputStreamReader.java:185)
  java.base at 13-ea/java.io.BufferedReader.fill(BufferedReader.java:161)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:326)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:392)
  main$talkTo_IO.readLineImpl(main.java:10760)
  main$DialogIO.waitForLine(main.java:10577)
  main$DialogIO.readLine(main.java:10587)
  main$StefansOS_ConnectToServer$2.run(main.java:9751)
  main$17.run(main.java:3906)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1021220: if (!stopped.isUp()) thread.trigger(),5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Java Sound Event Dispatcher,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.Object.wait(Object.java:326)
  java.desktop at 13-ea/com.sun.media.sound.EventDispatcher.dispatchEvents(EventDispatcher.java:173)
  java.desktop at 13-ea/com.sun.media.sound.EventDispatcher.run(EventDispatcher.java:212)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Image Fetcher 3,8,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.desktop at 13-ea/sun.awt.image.ImageFetcher.nextImage(ImageFetcher.java:154)
  java.desktop at 13-ea/sun.awt.image.ImageFetcher.fetchloop(ImageFetcher.java:207)
  java.desktop at 13-ea/sun.awt.image.ImageFetcher.run(ImageFetcher.java:176)

Thread[Connect,5,main]
  java.base at 13-ea/sun.nio.ch.Net.poll(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:182)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:286)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
  java.base at 13-ea/java.net.Socket$SocketInputStream.read(Socket.java:919)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:297)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
  java.base at 13-ea/java.io.InputStreamReader.read(InputStreamReader.java:185)
  java.base at 13-ea/java.io.BufferedReader.fill(BufferedReader.java:161)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:326)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:392)
  main$talkTo_IO.readLineImpl(main.java:12048)
  main$DialogIO.waitForLine(main.java:11342)
  main$DialogIO.readLine(main.java:11352)
  main$StefansOS_ConnectToServer$2.run(main.java:10401)
  main$55.run(main.java:3526)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Timer-27435,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.Object.wait(Object.java:326)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:527)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Connect,5,main]
  java.base at 13-ea/sun.nio.ch.Net.poll(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:182)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:286)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
  java.base at 13-ea/java.net.Socket$SocketInputStream.read(Socket.java:919)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:297)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
  java.base at 13-ea/java.io.InputStreamReader.read(InputStreamReader.java:185)
  java.base at 13-ea/java.io.BufferedReader.fill(BufferedReader.java:161)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:326)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:392)
  main$talkTo_IO.readLineImpl(m1024932.java:20632)
  main$DialogIO.waitForLine(m1024932.java:27380)
  main$DialogIO.readLine(m1024932.java:27387)
  main$StefansOS_ConnectToServer$2.run(m1024932.java:24283)
  main$283.run(m1024932.java:15905)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Finalizer,8,system]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155)
  java.base at 13-ea/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176)
  java.base at 13-ea/java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:170)

Thread[process reaper,10,system]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
  java.base at 13-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
  java.base at 13-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
  java.base at 13-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1053)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Reference Handler,10,system]
  java.base at 13-ea/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
  java.base at 13-ea/java.lang.ref.Reference.processPendingReferences(Reference.java:241)
  java.base at 13-ea/java.lang.ref.Reference$ReferenceHandler.run(Reference.java:213)

Thread[#1016183: actualUpdate();,5,main]
  java.base at 13-ea/sun.nio.ch.Net.poll(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:182)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:286)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
  java.base at 13-ea/java.net.Socket$SocketInputStream.read(Socket.java:919)
  java.base at 13-ea/java.io.BufferedInputStream.fill(BufferedInputStream.java:245)
  java.base at 13-ea/java.io.BufferedInputStream.read1(BufferedInputStream.java:285)
  java.base at 13-ea/java.io.BufferedInputStream.read(BufferedInputStream.java:344)
  java.base at 13-ea/sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:746)
  java.base at 13-ea/sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:689)
  java.base at 13-ea/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1610)
  java.base at 13-ea/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
  java.base at 13-ea/sun.net.www.protocol.http.HttpURLConnection.getHeaderFields(HttpURLConnection.java:3113)
  loadableUtils.utils.loadPage(utils.java:2749)
  loadableUtils.utils.loadPage(utils.java:2733)
  loadableUtils.utils.loadPageSilently(utils.java:2688)
  loadableUtils.utils.loadPageSilently(utils.java:2673)
  main.ai1_visitorsInfo(main.java:654)
  main.ai1_cookiesToday(main.java:333)
  main$HomePageVisitors.actualUpdate(main.java:140)
  main$HomePageVisitors$1.run(main.java:126)
  app//x30_pkg.x30_util.callF(x30_util.java:687)
  main.callF(main.java:159)
  main.callFunction(main.java:2078)
  main.pcallFunction(main.java:1732)
  main.pcallF(main.java:1251)
  main$SmartTimerTask.run(main.java:1466)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:556)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Single Thread,6,main]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  main.sleep(m1024932.java:3855)
  main$41.run(m1024932.java:2256)
  main.callF(m1024932.java:2390)
  main.callFunction(m1024932.java:16955)
  main.pcallFunction(m1024932.java:11028)
  main.pcallF(m1024932.java:4922)
  main$ReliableSingleThread._run(m1024932.java:25327)
  main$ReliableSingleThread$1.run(m1024932.java:25302)
  main$283.run(m1024932.java:15905)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[TimerQueue,5,system]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:235)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
  java.base at 13-ea/java.util.concurrent.DelayQueue.take(DelayQueue.java:229)
  java.desktop at 13-ea/javax.swing.TimerQueue.run(TimerQueue.java:171)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[AWT-EventQueue-0,6,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.desktop at 13-ea/java.awt.EventQueue.getNextEvent(EventQueue.java:566)
  java.desktop at 13-ea/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:190)
  java.desktop at 13-ea/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
  java.desktop at 13-ea/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
  java.desktop at 13-ea/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
  java.desktop at 13-ea/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
  java.desktop at 13-ea/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Thread[Displayer,6,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.base at 13-ea/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417)
  java.desktop at 13-ea/sun.awt.X11.InfoWindow$Balloon$Displayer.run(InfoWindow.java:493)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[DestroyJavaVM,5,main]

Thread[Java2D Disposer,10,system]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:155)
  java.base at 13-ea/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:176)
  java.desktop at 13-ea/sun.java2d.Disposer.run(Disposer.java:144)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1022108: testIt();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1024434: if (!enabled) return;
      for (String id : dm_listModuleIDs()) p...,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1025132,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[AWT-XAWT,6,system]
  java.desktop at 13-ea/sun.awt.X11.XToolkit.waitForEvents(Native Method)
  java.desktop at 13-ea/sun.awt.X11.XToolkit.run(XToolkit.java:692)
  java.desktop at 13-ea/sun.awt.X11.XToolkit.run(XToolkit.java:656)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Thread-28,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.desktop at 13-ea/com.sun.media.sound.DirectAudioDevice$DirectTDL.read(DirectAudioDevice.java:955)
  main$recordToAudioListeners_AudioLoop.run(main.java:345)

Thread[Timer-27443,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1024932,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Connect,5,main]
  java.base at 13-ea/sun.nio.ch.Net.poll(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:182)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:286)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
  java.base at 13-ea/java.net.Socket$SocketInputStream.read(Socket.java:919)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:297)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339)
  java.base at 13-ea/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
  java.base at 13-ea/java.io.InputStreamReader.read(InputStreamReader.java:185)
  java.base at 13-ea/java.io.BufferedReader.fill(BufferedReader.java:161)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:326)
  java.base at 13-ea/java.io.BufferedReader.readLine(BufferedReader.java:392)
  main$talkTo_IO.readLineImpl(main.java:6108)
  main$DialogIO.waitForLine(main.java:5555)
  main$DialogIO.readLine(main.java:5562)
  main$StefansOS_ConnectToServer$2.run(main.java:5316)
  main$45.run(main.java:7469)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[Signal Dispatcher,9,system]

Thread[#1019834: renderBoxes();,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Single Thread,6,main]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  main.sleep(m1024932.java:3855)
  main$41.run(m1024932.java:2256)
  main.callF(m1024932.java:2390)
  main.callFunction(m1024932.java:16955)
  main.pcallFunction(m1024932.java:11028)
  main.pcallF(m1024932.java:4922)
  main$ReliableSingleThread._run(m1024932.java:25327)
  main$ReliableSingleThread$1.run(m1024932.java:25302)
  main$283.run(m1024932.java:15905)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[StdOut Piper,5,main]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  app//x30.sleep(x30.java:2550)
  app//x30.run(x30.java:1898)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1024932: main$46 at 6b0c2d26,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Displayer,6,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.base at 13-ea/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417)
  java.desktop at 13-ea/sun.awt.X11.InfoWindow$Balloon$Displayer.run(InfoWindow.java:493)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[A timer by ?,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1025132,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1016073: main$ReliableSingleThread at 121e4f78,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1016872,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1020622: Pt mouse = Pt(mousePosition());
      if (neq(lastMousePosition, m...,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1024932: allRegularFixes();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1024932: clearSnippetTitleCacheIfOnline();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[JNativeHook Hook Thread,10,main]
  org.jnativehook.GlobalScreen$NativeHookThread.enable(Native Method)
  org.jnativehook.GlobalScreen$NativeHookThread.run(Unknown Source)

Thread[#1025144: actualUpdate();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[MouseMover,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1019644,6,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[JNativeHook Dispatch Thread,10,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.base at 13-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
  java.base at 13-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[#1024201: actualUpdate();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1024208: updateMe();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Socket accept port 5000,5,main]
  java.base at 13-ea/sun.nio.ch.Net.accept(Native Method)
  java.base at 13-ea/sun.nio.ch.NioSocketImpl.accept(NioSocketImpl.java:755)
  java.base at 13-ea/java.net.ServerSocket.implAccept(ServerSocket.java:649)
  java.base at 13-ea/java.net.ServerSocket.platformImplAccept(ServerSocket.java:615)
  java.base at 13-ea/java.net.ServerSocket.implAccept(ServerSocket.java:591)
  java.base at 13-ea/java.net.ServerSocket.implAccept(ServerSocket.java:548)
  java.base at 13-ea/java.net.ServerSocket.accept(ServerSocket.java:505)
  app//x30$83.run(x30.java:12265)

Thread[AWT-Shutdown,5,system]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.lang.Object.wait(Object.java:326)
  java.desktop at 13-ea/sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:291)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

Thread[A timer by #1025132,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[AutoVMExit,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1016932: setField("recommendedModules" , mapKeys psI(indexByField moduleID(s...,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[A timer by #1024932,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Keep-Alive-Timer,8,InnocuousThreadGroup]
  java.base at 13-ea/java.lang.Thread.sleep(Native Method)
  java.base at 13-ea/sun.net.www.http.KeepAliveCache.run(KeepAliveCache.java:168)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)
  java.base at 13-ea/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:134)

Thread[#1018523: actualUpdate();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[#1025132: temp enter();  gather();,5,main]
  java.base at 13-ea/java.lang.Object.wait(Native Method)
  java.base at 13-ea/java.util.TimerThread.mainLoop(Timer.java:553)
  java.base at 13-ea/java.util.TimerThread.run(Timer.java:506)

Thread[Displayer,6,main]
  java.base at 13-ea/jdk.internal.misc.Unsafe.park(Native Method)
  java.base at 13-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  java.base at 13-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081)
  java.base at 13-ea/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417)
  java.desktop at 13-ea/sun.awt.X11.InfoWindow$Balloon$Displayer.run(InfoWindow.java:493)
  java.base at 13-ea/java.lang.Thread.run(Thread.java:830)

75 threads.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 14 21:50:51 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 14 Sep 2019 23:50:51 +0200
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
 <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
Message-ID: <CAC2-jLEOk_PKvOUQ-q81HjyQ8UcTJsny2rYi0KJhyW7Q7=cpLg@mail.gmail.com>

I will also try the gdb method... that one sounds like a very smart idea.

On Sat, 14 Sep 2019 at 23:49, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hi,
>
> thanks for your answer. Unfortunately, I still don't know what triggers
> the "bad" state, so no test case... It happens randomly, but as I said,
> once it does, it doesn't go away anymore. (Still happening right now.)
>
> Would the result from Thread.getAllStackTraces() help? I attached that to
> this email.
>
> Many greetings,
> Stefan
>
>
> On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:
>
>> Hi Stefan,
>>
>> Is it possible for you to create a test case that reproduce this problem?
>>
>> If not, try running the program inside a Linux terminal, and when the
>> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
>> states of all the threads that the JVM knows about. It might give you
>> some idea what's happening.
>>
>> An alternative is to run your program inside gdb,
>>
>> $ gdb jdk13/bin/java
>> (gdb) handle SIGSEGV noprint
>> (gdb) handle SIGSEGV nostop
>> (gdb) set print thread-events off
>> (gdb) set height 0
>> (gdb) run -cp myapp.jar App
>>
>> (When the program enters the 100% CPU state, type Ctrl-C)
>>
>> ^C
>> Thread 1 "java" received signal SIGINT, Interrupt.
>> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
>> thread_return=0x7fffffff8508) at pthread_join.c:90
>> 90    pthread_join.c: No such file or directory.
>> (gdb) thread apply all where
>>
>> This will list all stacks of all the threads, including ones that the
>> JVM may not be aware of. This should tell you who is spinning the CPU.
>>
>> Thanks
>> - Ioi
>>
>>
>>
>>
>> On 9/14/19 1:57 PM, Stefan Reich wrote:
>> > Hi,
>> >
>> > I was advised by Oracle's Fairoz Matte to contact this list.
>> >
>> > I am seeing a Java process use 100% of one CPU core continuously, but no
>> > Java threads are runnable (as evidenced by internal thread sampling as
>> well
>> > as VisualVM).
>> >
>> > Whenever it occurs, the problem does not seem to go away until the Java
>> VM
>> > exits.
>> >
>> > I think I am using a single native library (OSHI), the rest is pure
>> Java.
>> >
>> > Older versions of the JDK have exhibited the same problem, but most
>> > interestingly, the bug is happening right now on a Linux machine
>> > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>> >
>> > I can perform any test on this machine that you instruct me to.
>> >
>> > Please advise,
>> > Stefan
>> >
>>
>>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 14 22:09:47 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sun, 15 Sep 2019 00:09:47 +0200
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLEOk_PKvOUQ-q81HjyQ8UcTJsny2rYi0KJhyW7Q7=cpLg@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
 <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
 <CAC2-jLEOk_PKvOUQ-q81HjyQ8UcTJsny2rYi0KJhyW7Q7=cpLg@mail.gmail.com>
Message-ID: <CAC2-jLEdeox-pHtuM8pVtTjwxJU25AvCUOHMH2m7a3Q3AeWggA@mail.gmail.com>

gdb is segfaulting...

> BFD: reopening /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp:
No such file or directory
>
> BFD: reopening /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp:
No such file or directory
>
> Can't read data for section '.eh_frame' in file
'/home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp'

I'm guessing the OSHI library is the trigger as it uses JNA. The same
module loads fine without gdb though.


On Sat, 14 Sep 2019 at 23:50, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> I will also try the gdb method... that one sounds like a very smart idea.
>
> On Sat, 14 Sep 2019 at 23:49, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Hi,
>>
>> thanks for your answer. Unfortunately, I still don't know what triggers
>> the "bad" state, so no test case... It happens randomly, but as I said,
>> once it does, it doesn't go away anymore. (Still happening right now.)
>>
>> Would the result from Thread.getAllStackTraces() help? I attached that
>> to this email.
>>
>> Many greetings,
>> Stefan
>>
>>
>> On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:
>>
>>> Hi Stefan,
>>>
>>> Is it possible for you to create a test case that reproduce this problem?
>>>
>>> If not, try running the program inside a Linux terminal, and when the
>>> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
>>> states of all the threads that the JVM knows about. It might give you
>>> some idea what's happening.
>>>
>>> An alternative is to run your program inside gdb,
>>>
>>> $ gdb jdk13/bin/java
>>> (gdb) handle SIGSEGV noprint
>>> (gdb) handle SIGSEGV nostop
>>> (gdb) set print thread-events off
>>> (gdb) set height 0
>>> (gdb) run -cp myapp.jar App
>>>
>>> (When the program enters the 100% CPU state, type Ctrl-C)
>>>
>>> ^C
>>> Thread 1 "java" received signal SIGINT, Interrupt.
>>> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
>>> thread_return=0x7fffffff8508) at pthread_join.c:90
>>> 90    pthread_join.c: No such file or directory.
>>> (gdb) thread apply all where
>>>
>>> This will list all stacks of all the threads, including ones that the
>>> JVM may not be aware of. This should tell you who is spinning the CPU.
>>>
>>> Thanks
>>> - Ioi
>>>
>>>
>>>
>>>
>>> On 9/14/19 1:57 PM, Stefan Reich wrote:
>>> > Hi,
>>> >
>>> > I was advised by Oracle's Fairoz Matte to contact this list.
>>> >
>>> > I am seeing a Java process use 100% of one CPU core continuously, but
>>> no
>>> > Java threads are runnable (as evidenced by internal thread sampling as
>>> well
>>> > as VisualVM).
>>> >
>>> > Whenever it occurs, the problem does not seem to go away until the
>>> Java VM
>>> > exits.
>>> >
>>> > I think I am using a single native library (OSHI), the rest is pure
>>> Java.
>>> >
>>> > Older versions of the JDK have exhibited the same problem, but most
>>> > interestingly, the bug is happening right now on a Linux machine
>>> > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>>> >
>>> > I can perform any test on this machine that you instruct me to.
>>> >
>>> > Please advise,
>>> > Stefan
>>> >
>>>
>>>
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Sun Sep 15 02:03:23 2019
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 15 Sep 2019 12:03:23 +1000
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
Message-ID: <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>

Hi Jie,

On 14/09/2019 7:00 pm, Jie Fu wrote:
> Hi all,
> 
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231024
> Webrev: http://cr.openjdk.java.net/~jiefu/8231024/webrev.00/
> 
> *Background*
> When I was running a jtreg test with
> ------------------------------------
> make test 
> TEST="test/jdk/java/lang/invoke/TestCatchExceptionWithVarargs.java" 
> CONF=fast
> ------------------------------------
> I got some VM warnings which just told me to increase O_BUFLEN in 
> ostream.hpp.
> But the debug info didn't tell us the proper value of O_BUFLEN needed by 
> the output.
> 
> It might be better to dump the required value of O_BUFLEN.
> 
> *Fix*
> 
> - Before the patch
> ------------------------------------
> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> ...
> ------------------------------------
> 
> - After the patch
> ------------------------------------
> [2019-09-14 16:19:09,478] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp: at least 2013 is required -- 
> output truncated
> [2019-09-14 16:19:09,482] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp: at least 2031 is required -- 
> output truncated
> [2019-09-14 16:19:09,488] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp: at least 2049 is required -- 
> output truncated
> ------------------------------------
> 
> Could you please review it?

Looks good. But given this keeps reporting different values, the input 
buffer size must be different in each case, so printing that size as 
well could also be useful for tracing back to the callsite. There seems 
to be as assumption that the buffer is always O_BUFLEN in size but as it 
is set to 2000 that can't be the case. In which case the error message 
itself seems somewhat misleading.

Thanks,
David

> Thanks a lot.
> Best regards,
> Jie
> 
> 

From david.holmes at oracle.com  Sun Sep 15 02:12:04 2019
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 15 Sep 2019 12:12:04 +1000
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
 <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
Message-ID: <3aba9d29-86a4-0a19-77ff-ab50a88cc631@oracle.com>

Hi Stefan,

On 15/09/2019 7:49 am, Stefan Reich wrote:
> Hi,
> 
> thanks for your answer. Unfortunately, I still don't know what triggers the
> "bad" state, so no test case... It happens randomly, but as I said, once it
> does, it doesn't go away anymore. (Still happening right now.)
> 
> Would the result from Thread.getAllStackTraces() help? I attached that to
> this email.

Possible - though ideally we would want to see all threads not just Java 
threads. But looking at the list you gave I see one suspicious thread:

Thread[JNativeHook Hook Thread,10,main]
   org.jnativehook.GlobalScreen$NativeHookThread.enable(Native Method)
   org.jnativehook.GlobalScreen$NativeHookThread.run(Unknown Source)

You might want to check what the code for that thread does.

Also try to identify the thread involved via top:

https://stackoverflow.com/questions/930915/which-java-thread-is-hogging-the-cpu

Cheers,
David

> Many greetings,
> Stefan
> 
> 
> On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
>> Hi Stefan,
>>
>> Is it possible for you to create a test case that reproduce this problem?
>>
>> If not, try running the program inside a Linux terminal, and when the
>> CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It lists the
>> states of all the threads that the JVM knows about. It might give you
>> some idea what's happening.
>>
>> An alternative is to run your program inside gdb,
>>
>> $ gdb jdk13/bin/java
>> (gdb) handle SIGSEGV noprint
>> (gdb) handle SIGSEGV nostop
>> (gdb) set print thread-events off
>> (gdb) set height 0
>> (gdb) run -cp myapp.jar App
>>
>> (When the program enters the 100% CPU state, type Ctrl-C)
>>
>> ^C
>> Thread 1 "java" received signal SIGINT, Interrupt.
>> 0x00007ffff779798d in pthread_join (threadid=140737353910016,
>> thread_return=0x7fffffff8508) at pthread_join.c:90
>> 90    pthread_join.c: No such file or directory.
>> (gdb) thread apply all where
>>
>> This will list all stacks of all the threads, including ones that the
>> JVM may not be aware of. This should tell you who is spinning the CPU.
>>
>> Thanks
>> - Ioi
>>
>>
>>
>>
>> On 9/14/19 1:57 PM, Stefan Reich wrote:
>>> Hi,
>>>
>>> I was advised by Oracle's Fairoz Matte to contact this list.
>>>
>>> I am seeing a Java process use 100% of one CPU core continuously, but no
>>> Java threads are runnable (as evidenced by internal thread sampling as
>> well
>>> as VisualVM).
>>>
>>> Whenever it occurs, the problem does not seem to go away until the Java
>> VM
>>> exits.
>>>
>>> I think I am using a single native library (OSHI), the rest is pure Java.
>>>
>>> Older versions of the JDK have exhibited the same problem, but most
>>> interestingly, the bug is happening right now on a Linux machine
>>> (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>>>
>>> I can perform any test on this machine that you instruct me to.
>>>
>>> Please advise,
>>> Stefan
>>>
>>
>>
> 

From ioi.lam at oracle.com  Sun Sep 15 05:14:34 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sat, 14 Sep 2019 22:14:34 -0700
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLEdeox-pHtuM8pVtTjwxJU25AvCUOHMH2m7a3Q3AeWggA@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
 <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
 <CAC2-jLEOk_PKvOUQ-q81HjyQ8UcTJsny2rYi0KJhyW7Q7=cpLg@mail.gmail.com>
 <CAC2-jLEdeox-pHtuM8pVtTjwxJU25AvCUOHMH2m7a3Q3AeWggA@mail.gmail.com>
Message-ID: <ded4ab9c-df52-4fec-3bf5-23b09554276d@oracle.com>

Which version of gdb are you using? Maybe try upgrading gdb to a newer 
version? You might have to build it yourself, but that should be quite 
straight-forward on Linux.

https://www.mapleprimes.com/questions/207040-Gdb-Crashes-When-Linking-To-OpenMaple-Library

Another option is to send a kill signal to your process to create a core 
dump, and see if gdb can open the core file without crashing.

See 
https://stackoverflow.com/questions/26727978/gdb-issue-bfd-reopening-tmp-no-such-file-or-directory/26767392#26767392

Hopefully gdb won't do lazy loading when handling core files.

Thanks
- Ioi


On 9/14/19 3:09 PM, Stefan Reich wrote:
> gdb is segfaulting...
>
> > BFD: reopening 
> /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp: No such file 
> or directory
> >
> > BFD: reopening 
> /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp: No such file 
> or directory
> >
> > Can't read data for section '.eh_frame' in file 
> '/home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp'
>
> I'm guessing the OSHI library is the trigger as it uses JNA. The same 
> module loads fine without gdb though.
>
>
> On Sat, 14 Sep 2019 at 23:50, Stefan Reich 
> <stefan.reich.maker.of.eye at googlemail.com 
> <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
>
>     I will also try the gdb method... that one sounds like a very
>     smart idea.
>
>     On Sat, 14 Sep 2019 at 23:49, Stefan Reich
>     <stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
>
>         Hi,
>
>         thanks for your answer. Unfortunately, I still don't know what
>         triggers the "bad" state, so no test case... It happens
>         randomly, but as I said, once it does, it doesn't go away
>         anymore. (Still happening right now.)
>
>         Would the result from Thread.getAllStackTraces() help? I
>         attached that to this email.
>
>         Many greetings,
>         Stefan
>
>
>         On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com
>         <mailto:ioi.lam at oracle.com>> wrote:
>
>             Hi Stefan,
>
>             Is it possible for you to create a test case that
>             reproduce this problem?
>
>             If not, try running the program inside a Linux terminal,
>             and when the
>             CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It
>             lists the
>             states of all the threads that the JVM knows about. It
>             might give you
>             some idea what's happening.
>
>             An alternative is to run your program inside gdb,
>
>             $ gdb jdk13/bin/java
>             (gdb) handle SIGSEGV noprint
>             (gdb) handle SIGSEGV nostop
>             (gdb) set print thread-events off
>             (gdb) set height 0
>             (gdb) run -cp myapp.jar App
>
>             (When the program enters the 100% CPU state, type Ctrl-C)
>
>             ^C
>             Thread 1 "java" received signal SIGINT, Interrupt.
>             0x00007ffff779798d in pthread_join (threadid=140737353910016,
>             thread_return=0x7fffffff8508) at pthread_join.c:90
>             90??? pthread_join.c: No such file or directory.
>             (gdb) thread apply all where
>
>             This will list all stacks of all the threads, including
>             ones that the
>             JVM may not be aware of. This should tell you who is
>             spinning the CPU.
>
>             Thanks
>             - Ioi
>
>
>
>
>             On 9/14/19 1:57 PM, Stefan Reich wrote:
>             > Hi,
>             >
>             > I was advised by Oracle's Fairoz Matte to contact this list.
>             >
>             > I am seeing a Java process use 100% of one CPU core
>             continuously, but no
>             > Java threads are runnable (as evidenced by internal
>             thread sampling as well
>             > as VisualVM).
>             >
>             > Whenever it occurs, the problem does not seem to go away
>             until the Java VM
>             > exits.
>             >
>             > I think I am using a single native library (OSHI), the
>             rest is pure Java.
>             >
>             > Older versions of the JDK have exhibited the same
>             problem, but most
>             > interestingly, the bug is happening right now on a Linux
>             machine
>             > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
>             >
>             > I can perform any test on this machine that you instruct
>             me to.
>             >
>             > Please advise,
>             > Stefan
>             >
>
>
>
>         -- 
>         Stefan Reich
>         BotCompany.de // Java-based operating systems
>
>
>
>     -- 
>     Stefan Reich
>     BotCompany.de // Java-based operating systems
>
>
>
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems


From andrei.pangin at gmail.com  Sun Sep 15 06:11:46 2019
From: andrei.pangin at gmail.com (Andrei Pangin)
Date: Sat, 14 Sep 2019 23:11:46 -0700
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <ded4ab9c-df52-4fec-3bf5-23b09554276d@oracle.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
 <3a3b41e8-66cf-16f0-1845-e0520eb5645a@oracle.com>
 <CAC2-jLHkWgVa1ws5Ea4rOMLiS79kCZRONVhk58ThBRK8-CH3mg@mail.gmail.com>
 <CAC2-jLEOk_PKvOUQ-q81HjyQ8UcTJsny2rYi0KJhyW7Q7=cpLg@mail.gmail.com>
 <CAC2-jLEdeox-pHtuM8pVtTjwxJU25AvCUOHMH2m7a3Q3AeWggA@mail.gmail.com>
 <ded4ab9c-df52-4fec-3bf5-23b09554276d@oracle.com>
Message-ID: <CAAnUXCk9+_UZDnv6HCgeg-CU-==q3a3h6FNK7hhF1=5C-saOCQ@mail.gmail.com>

Hi Stefan,

I think, async-profiler (
https://github.com/jvm-profiling-tools/async-profiler/) may give an idea
what's going on, since it collects the mixed profile including Java +
native + VM threads.
E.g. when the problem happens again, run the following command
./profiler.sh -d 20 -t -f profile.svg PID
(which means, collect CPU profile for 20 seconds in threaded mode and save
the output to profile.svg).

The last time I saw a similar issue, it was a C2 compiler thread falling
into an infinite loop (though that particular issue should have already
been fixed - https://bugs.openjdk.java.net/browse/JDK-8219448).

In this case, jstack or kill -3 PID should help, as the thread dump will
include compiler threads with the methods being compiled.

Regards,
Andrei

??, 14 ????. 2019 ?. ? 22:16, Ioi Lam <ioi.lam at oracle.com>:

> Which version of gdb are you using? Maybe try upgrading gdb to a newer
> version? You might have to build it yourself, but that should be quite
> straight-forward on Linux.
>
>
> https://www.mapleprimes.com/questions/207040-Gdb-Crashes-When-Linking-To-OpenMaple-Library
>
> Another option is to send a kill signal to your process to create a core
> dump, and see if gdb can open the core file without crashing.
>
> See
>
> https://stackoverflow.com/questions/26727978/gdb-issue-bfd-reopening-tmp-no-such-file-or-directory/26767392#26767392
>
> Hopefully gdb won't do lazy loading when handling core files.
>
> Thanks
> - Ioi
>
>
> On 9/14/19 3:09 PM, Stefan Reich wrote:
> > gdb is segfaulting...
> >
> > > BFD: reopening
> > /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp: No such file
> > or directory
> > >
> > > BFD: reopening
> > /home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp: No such file
> > or directory
> > >
> > > Can't read data for section '.eh_frame' in file
> > '/home/stefan/.cache/JNA/temp/jna11400456213745436559.tmp'
> >
> > I'm guessing the OSHI library is the trigger as it uses JNA. The same
> > module loads fine without gdb though.
> >
> >
> > On Sat, 14 Sep 2019 at 23:50, Stefan Reich
> > <stefan.reich.maker.of.eye at googlemail.com
> > <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
> >
> >     I will also try the gdb method... that one sounds like a very
> >     smart idea.
> >
> >     On Sat, 14 Sep 2019 at 23:49, Stefan Reich
> >     <stefan.reich.maker.of.eye at googlemail.com
> >     <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
> >
> >         Hi,
> >
> >         thanks for your answer. Unfortunately, I still don't know what
> >         triggers the "bad" state, so no test case... It happens
> >         randomly, but as I said, once it does, it doesn't go away
> >         anymore. (Still happening right now.)
> >
> >         Would the result from Thread.getAllStackTraces() help? I
> >         attached that to this email.
> >
> >         Many greetings,
> >         Stefan
> >
> >
> >         On Sat, 14 Sep 2019 at 23:43, Ioi Lam <ioi.lam at oracle.com
> >         <mailto:ioi.lam at oracle.com>> wrote:
> >
> >             Hi Stefan,
> >
> >             Is it possible for you to create a test case that
> >             reproduce this problem?
> >
> >             If not, try running the program inside a Linux terminal,
> >             and when the
> >             CPU goes at 100%, type "Ctrl-\" (Control + Backslash). It
> >             lists the
> >             states of all the threads that the JVM knows about. It
> >             might give you
> >             some idea what's happening.
> >
> >             An alternative is to run your program inside gdb,
> >
> >             $ gdb jdk13/bin/java
> >             (gdb) handle SIGSEGV noprint
> >             (gdb) handle SIGSEGV nostop
> >             (gdb) set print thread-events off
> >             (gdb) set height 0
> >             (gdb) run -cp myapp.jar App
> >
> >             (When the program enters the 100% CPU state, type Ctrl-C)
> >
> >             ^C
> >             Thread 1 "java" received signal SIGINT, Interrupt.
> >             0x00007ffff779798d in pthread_join (threadid=140737353910016,
> >             thread_return=0x7fffffff8508) at pthread_join.c:90
> >             90    pthread_join.c: No such file or directory.
> >             (gdb) thread apply all where
> >
> >             This will list all stacks of all the threads, including
> >             ones that the
> >             JVM may not be aware of. This should tell you who is
> >             spinning the CPU.
> >
> >             Thanks
> >             - Ioi
> >
> >
> >
> >
> >             On 9/14/19 1:57 PM, Stefan Reich wrote:
> >             > Hi,
> >             >
> >             > I was advised by Oracle's Fairoz Matte to contact this
> list.
> >             >
> >             > I am seeing a Java process use 100% of one CPU core
> >             continuously, but no
> >             > Java threads are runnable (as evidenced by internal
> >             thread sampling as well
> >             > as VisualVM).
> >             >
> >             > Whenever it occurs, the problem does not seem to go away
> >             until the Java VM
> >             > exits.
> >             >
> >             > I think I am using a single native library (OSHI), the
> >             rest is pure Java.
> >             >
> >             > Older versions of the JDK have exhibited the same
> >             problem, but most
> >             > interestingly, the bug is happening right now on a Linux
> >             machine
> >             > (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
> >             >
> >             > I can perform any test on this machine that you instruct
> >             me to.
> >             >
> >             > Please advise,
> >             > Stefan
> >             >
> >
> >
> >
> >         --
> >         Stefan Reich
> >         BotCompany.de // Java-based operating systems
> >
> >
> >
> >     --
> >     Stefan Reich
> >     BotCompany.de // Java-based operating systems
> >
> >
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
>
>

From erik.gahlin at oracle.com  Sun Sep 15 09:57:59 2019
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Sun, 15 Sep 2019 11:57:59 +0200
Subject: JDK 13 EA: 100% CPU use with no Java threads runnable
In-Reply-To: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
References: <CAC2-jLEJQb8F_8_3ewNk3XgD0ijmxUdtarjocdJj0_-zd8Erzg@mail.gmail.com>
Message-ID: <BB55B8D4-6C9A-45B0-B901-4CC690F31FFC@oracle.com>

There is also JFR.

$ java -XX:StartFlightRecording:filename=dump.jfr ?

or 

$ jcmd <pid> JFR.start duration=10s filename=dump.jfr

Open the file in JMC and select Native Method Sample. It will show threads that are in native. You can also print the events from command line, but it may a bit too many samples, i.e.

$ jfr print ?events NativeMethodSample,CPULoad dump.jfr

Erik

> On 14 Sep 2019, at 22:57, Stefan Reich <stefan.reich.maker.of.eye at googlemail.com> wrote:
> 
> Hi,
> 
> I was advised by Oracle's Fairoz Matte to contact this list.
> 
> I am seeing a Java process use 100% of one CPU core continuously, but no
> Java threads are runnable (as evidenced by internal thread sampling as well
> as VisualVM).
> 
> Whenever it occurs, the problem does not seem to go away until the Java VM
> exits.
> 
> I think I am using a single native library (OSHI), the rest is pure Java.
> 
> Older versions of the JDK have exhibited the same problem, but most
> interestingly, the bug is happening right now on a Linux machine
> (Peppermint 7 I think) with OpenJDK 13 EA Build 31.
> 
> I can perform any test on this machine that you instruct me to.
> 
> Please advise,
> Stefan
> 
> -- 
> Stefan Reich
> BotCompany.de // Java-based operating systems


From david.holmes at oracle.com  Sun Sep 15 23:49:09 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Sep 2019 09:49:09 +1000
Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after JSR-166
 refresh
Message-ID: <becc0d86-2338-a90c-2bef-68bf1c3e923a@oracle.com>

Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033
       https://bugs.openjdk.java.net/browse/JDK-8231034

webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/
(inline below)

A bunch of mainly management tests (mostly in hotspot repo) are failing 
after the JSR-166 refresh to due changes in stack information and usage. 
These are causing significant disruption to our CI and so need to be 
ProblemListed while the tests are investigated and fixed.

Testing: tier 1 - 3 (in progress)

Thanks,
David

--- old/test/hotspot/jtreg/ProblemList.txt	2019-09-15 19:41:48.446127451 
-0400
+++ new/test/hotspot/jtreg/ProblemList.txt	2019-09-15 19:41:47.344115881 
-0400
@@ -90,6 +90,7 @@
  # :hotspot_runtime

  runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64
+runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all

 
#############################################################################

@@ -204,4 +205,16 @@

 
vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 
7199837 generic-all

+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java 
8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java 
8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java 
8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java 
8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java 
8231032 generic-all
+
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java 
8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java 
  8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java 
  8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java 
  8231032 generic-all
+vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java 
  8231032 generic-all
+
 
#############################################################################
--- old/test/jdk/ProblemList.txt	2019-09-15 19:41:51.817162845 -0400
+++ new/test/jdk/ProblemList.txt	2019-09-15 19:41:50.703151149 -0400
@@ -564,6 +564,8 @@
  javax/management/monitor/DerivedGaugeMonitorTest.java         8042211 
generic-all
 
javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java 
8042215 generic-all

+java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 
generic-all
+
 
############################################################################

  # jdk_io


From joe.darcy at oracle.com  Sun Sep 15 23:54:01 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 15 Sep 2019 16:54:01 -0700
Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after
 JSR-166 refresh
In-Reply-To: <becc0d86-2338-a90c-2bef-68bf1c3e923a@oracle.com>
References: <becc0d86-2338-a90c-2bef-68bf1c3e923a@oracle.com>
Message-ID: <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com>

Looks fine David; thanks,

-Joe

On 9/15/2019 4:49 PM, David Holmes wrote:
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033
> ????? https://bugs.openjdk.java.net/browse/JDK-8231034
>
> webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/
> (inline below)
>
> A bunch of mainly management tests (mostly in hotspot repo) are 
> failing after the JSR-166 refresh to due changes in stack information 
> and usage. These are causing significant disruption to our CI and so 
> need to be ProblemListed while the tests are investigated and fixed.
>
> Testing: tier 1 - 3 (in progress)
>
> Thanks,
> David
>
> --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 
> 19:41:48.446127451 -0400
> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 
> 19:41:47.344115881 -0400
> @@ -90,6 +90,7 @@
> ?# :hotspot_runtime
>
> ?runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64
> +runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all
>
>
> ############################################################################# 
>
>
> @@ -204,4 +205,16 @@
>
>
> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 
> 7199837 generic-all
>
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java 
> 8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java 
> 8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java 
> 8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java 
> 8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java 
> 8231032 generic-all
> +
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java 
> 8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java 
> ?8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java 
> ?8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java 
> ?8231032 generic-all
> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java 
> ?8231032 generic-all
> +
>
> ############################################################################# 
>
> --- old/test/jdk/ProblemList.txt??? 2019-09-15 19:41:51.817162845 -0400
> +++ new/test/jdk/ProblemList.txt??? 2019-09-15 19:41:50.703151149 -0400
> @@ -564,6 +564,8 @@
> ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 
> generic-all
>
> javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java 
> 8042215 generic-all
>
> +java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 
> generic-all
> +
>
> ############################################################################ 
>
>
> ?# jdk_io
>

From david.holmes at oracle.com  Sun Sep 15 23:57:01 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Sep 2019 09:57:01 +1000
Subject: Urgent RFR: 8231034/8231033 Problem list tetss failing after
 JSR-166 refresh
In-Reply-To: <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com>
References: <becc0d86-2338-a90c-2bef-68bf1c3e923a@oracle.com>
 <40a30e97-5ebc-8ece-47d2-96804afb022c@oracle.com>
Message-ID: <bdf96077-7af2-f4c4-6007-32efbe2ed3a6@oracle.com>

Thanks Joe. Will push once CI testing is verified.

David

On 16/09/2019 9:54 am, Joe Darcy wrote:
> Looks fine David; thanks,
> 
> -Joe
> 
> On 9/15/2019 4:49 PM, David Holmes wrote:
>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8231033
>> ????? https://bugs.openjdk.java.net/browse/JDK-8231034
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8231033-8231034/webrev/
>> (inline below)
>>
>> A bunch of mainly management tests (mostly in hotspot repo) are 
>> failing after the JSR-166 refresh to due changes in stack information 
>> and usage. These are causing significant disruption to our CI and so 
>> need to be ProblemListed while the tests are investigated and fixed.
>>
>> Testing: tier 1 - 3 (in progress)
>>
>> Thanks,
>> David
>>
>> --- old/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 
>> 19:41:48.446127451 -0400
>> +++ new/test/hotspot/jtreg/ProblemList.txt??? 2019-09-15 
>> 19:41:47.344115881 -0400
>> @@ -90,6 +90,7 @@
>> ?# :hotspot_runtime
>>
>> ?runtime/jni/terminatedThread/TestTerminatedThread.java 8219652 aix-ppc64
>> +runtime/ReservedStack/ReservedStackTest.java 8231031 generic-all
>>
>>
>> ############################################################################# 
>>
>>
>> @@ -204,4 +205,16 @@
>>
>>
>> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 
>> 7199837 generic-all
>>
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads001/TestDescription.java 
>> 8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads002/TestDescription.java 
>> 8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads003/TestDescription.java 
>> 8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads004/TestDescription.java 
>> 8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/SynchronizerLockingThreads/SynchronizerLockingThreads005/TestDescription.java 
>> 8231032 generic-all
>> +
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi001/Multi001.java 
>> 8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi002/TestDescription.java 
>> ?8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi003/TestDescription.java 
>> ?8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi004/TestDescription.java 
>> ?8231032 generic-all
>> +vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java 
>> ?8231032 generic-all
>> +
>>
>> ############################################################################# 
>>
>> --- old/test/jdk/ProblemList.txt??? 2019-09-15 19:41:51.817162845 -0400
>> +++ new/test/jdk/ProblemList.txt??? 2019-09-15 19:41:50.703151149 -0400
>> @@ -564,6 +564,8 @@
>> ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 
>> generic-all
>>
>> javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java 
>> 8042215 generic-all
>>
>> +java/lang/management/ThreadMXBean/LockedSynchronizers.java 8231032 
>> generic-all
>> +
>>
>> ############################################################################ 
>>
>>
>> ?# jdk_io
>>

From fujie at loongson.cn  Mon Sep 16 03:51:03 2019
From: fujie at loongson.cn (Jie Fu)
Date: Mon, 16 Sep 2019 11:51:03 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <72fc847c-352f-70e3-cdbf-21ed5cb94cb9@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <72fc847c-352f-70e3-cdbf-21ed5cb94cb9@oracle.com>
Message-ID: <c72f619a-6744-6713-25c7-86874b8b911c@loongson.cn>

Good catch, Ioi.
Will update the patch soon.
Thank you very much.

On 2019/9/15 ??5:45, Ioi Lam wrote:
> Hi Jie,
>
> I think this is a good idea, but the printed value is off by one when 
> add_cr is true.
>
> Thanks
> - Ioi
>
> On 9/14/19 2:00 AM, Jie Fu wrote:
>> Hi all,
>>
>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231024
>> Webrev: http://cr.openjdk.java.net/~jiefu/8231024/webrev.00/
>>
>> *Background*
>> When I was running a jtreg test with
>> ------------------------------------
>> make test 
>> TEST="test/jdk/java/lang/invoke/TestCatchExceptionWithVarargs.java" 
>> CONF=fast
>> ------------------------------------
>> I got some VM warnings which just told me to increase O_BUFLEN in 
>> ostream.hpp.
>> But the debug info didn't tell us the proper value of O_BUFLEN needed 
>> by the output.
>>
>> It might be better to dump the required value of O_BUFLEN.
>>
>> *Fix*
>>
>> - Before the patch
>> ------------------------------------
>> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> ...
>> ------------------------------------
>>
>> - After the patch
>> ------------------------------------
>> [2019-09-14 16:19:09,478] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp: at least 2013 is required 
>> -- output truncated
>> [2019-09-14 16:19:09,482] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp: at least 2031 is required 
>> -- output truncated
>> [2019-09-14 16:19:09,488] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp: at least 2049 is required 
>> -- output truncated
>> ------------------------------------
>>
>> Could you please review it?
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>>
>


From fujie at loongson.cn  Mon Sep 16 04:04:08 2019
From: fujie at loongson.cn (Jie Fu)
Date: Mon, 16 Sep 2019 12:04:08 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
Message-ID: <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>

Hi David,

Thank you for your review.
Will update the patch soon.
Please seem comments inline.

Best regards,
Jie

On 2019/9/15 ??10:03, David Holmes wrote:
> Looks good. But given this keeps reporting different values, the input 
> buffer size must be different in each case, so printing that size as 
> well could also be useful for tracing back to the callsite. 

OK. Will do.


> There seems to be as assumption that the buffer is always O_BUFLEN in 
> size but as it is set to 2000 that can't be the case. In which case 
> the error message itself seems somewhat misleading.
I agree that the error message itself seems somewhat misleading since 
apart from O_BUFLEN [1], BUFLEN [2] may also be used as the buffer size.

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138



From fujie at loongson.cn  Mon Sep 16 05:53:32 2019
From: fujie at loongson.cn (Jie Fu)
Date: Mon, 16 Sep 2019 13:53:32 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
Message-ID: <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>

Hi Ioi and David,

Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.01/
 ? -1) The printed value has been changed from written + 1 to written + 2;
 ? -2) The input buffer size has been printed;
 ? -3) Adjust the error message to avoid some misleading.

- Before the patch
------------------------------------
[2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
...
------------------------------------

- After the patch
------------------------------------
[2019-09-16 13:35:59,351] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
should be increased to 2014 or above -- output truncated
[2019-09-16 13:35:59,361] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
should be increased to 2032 or above -- output truncated
[2019-09-16 13:35:59,371] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
should be increased to 2050 or above -- output truncated
...
------------------------------------

Could you please review it and give me some advice?

Thanks a lot.
Best regards,
Jie


On 2019/9/16 ??12:04, Jie Fu wrote:
> Hi David,
>
> Thank you for your review.
> Will update the patch soon.
> Please seem comments inline.
>
> Best regards,
> Jie
>
> On 2019/9/15 ??10:03, David Holmes wrote:
>> Looks good. But given this keeps reporting different values, the 
>> input buffer size must be different in each case, so printing that 
>> size as well could also be useful for tracing back to the callsite. 
>
> OK. Will do.
>
>
>> There seems to be as assumption that the buffer is always O_BUFLEN in 
>> size but as it is set to 2000 that can't be the case. In which case 
>> the error message itself seems somewhat misleading.
> I agree that the error message itself seems somewhat misleading since 
> apart from O_BUFLEN [1], BUFLEN [2] may also be used as the buffer size.
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138
>


From david.holmes at oracle.com  Mon Sep 16 06:40:13 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Sep 2019 16:40:13 +1000
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
Message-ID: <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>

Hi Jie,

On 16/09/2019 3:53 pm, Jie Fu wrote:
> Hi Ioi and David,
> 
> Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.01/
>  ? -1) The printed value has been changed from written + 1 to written + 2;
>  ? -2) The input buffer size has been printed;
>  ? -3) Adjust the error message to avoid some misleading.
> 
> - Before the patch
> ------------------------------------
> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> ...
> ------------------------------------
> 
> - After the patch
> ------------------------------------
> [2019-09-16 13:35:59,351] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
> should be increased to 2014 or above -- output truncated
> [2019-09-16 13:35:59,361] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
> should be increased to 2032 or above -- output truncated
> [2019-09-16 13:35:59,371] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: The buffer size is 2000, which (e.g., O_BUFLEN or BUFLEN) 
> should be increased to 2050 or above -- output truncated
> ...
> ------------------------------------

Okay I'm confused. I had assumed that the passed in buffer size must be 
different in each case because of the 2014/2032/2050 values in the 
message, but in fact they are all sized at 2000. That makes no sense - 
how can we have written e.g. 2014 bytes to a buffer of only 2000 bytes? 
Do we have a bug in os::vsnprintf?

Thanks,
David
-----

> Could you please review it and give me some advice?
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> 
> On 2019/9/16 ??12:04, Jie Fu wrote:
>> Hi David,
>>
>> Thank you for your review.
>> Will update the patch soon.
>> Please seem comments inline.
>>
>> Best regards,
>> Jie
>>
>> On 2019/9/15 ??10:03, David Holmes wrote:
>>> Looks good. But given this keeps reporting different values, the 
>>> input buffer size must be different in each case, so printing that 
>>> size as well could also be useful for tracing back to the callsite. 
>>
>> OK. Will do.
>>
>>
>>> There seems to be as assumption that the buffer is always O_BUFLEN in 
>>> size but as it is set to 2000 that can't be the case. In which case 
>>> the error message itself seems somewhat misleading.
>> I agree that the error message itself seems somewhat misleading since 
>> apart from O_BUFLEN [1], BUFLEN [2] may also be used as the buffer size.
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>
>> [2] 
>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>
>>
> 

From fujie at loongson.cn  Mon Sep 16 07:09:28 2019
From: fujie at loongson.cn (Jie Fu)
Date: Mon, 16 Sep 2019 15:09:28 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
Message-ID: <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>

Hi David,

Sorry for the confusion.

On 2019/9/16 ??2:40, David Holmes wrote:
> Okay I'm confused. I had assumed that the passed in buffer size must 
> be different in each case because of the 2014/2032/2050 values in the 
> message, but in fact they are all sized at 2000. 
According to the source code, the buffer size can be either 
2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
So it isn't always 2000.

> That makes no sense
I think it makes sense.
It is still unclear which one (O_BUFLEN or BUFLEN?) should be increased 
if the current buffer size wasn't printed.


> - how can we have written e.g. 2014 bytes to a buffer of only 2000 bytes? 

The output is truncated since the current buffer size is too small 
(e.g., 2000 < 2014).


> Do we have a bug in os::vsnprintf?

I don't think so.

Thanks a lot.
Best regards,
Jie

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124
[2] 
http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138



From david.holmes at oracle.com  Mon Sep 16 07:44:35 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Sep 2019 17:44:35 +1000
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
Message-ID: <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>

On 16/09/2019 5:09 pm, Jie Fu wrote:
> Hi David,
> 
> Sorry for the confusion.

The confusion is mine, not from you :)

> On 2019/9/16 ??2:40, David Holmes wrote:
>> Okay I'm confused. I had assumed that the passed in buffer size must 
>> be different in each case because of the 2014/2032/2050 values in the 
>> message, but in fact they are all sized at 2000. 
> According to the source code, the buffer size can be either 
> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
> So it isn't always 2000.

It is 2000 is all three examples of the output that you gave.

>> That makes no sense
> I think it makes sense.
> It is still unclear which one (O_BUFLEN or BUFLEN?) should be increased 
> if the current buffer size wasn't printed.

You need to know the original caller that passed in the buffer size.

But we can't just keep increasing the buffer size. We probably need to 
examine the callers to see what amount of information is trying to be 
passed through. Then decide whether to adjust what the callers are 
passing through, or adjust the buffer size - perhaps on a callsite by 
callsite basis rather than just bumping O_BUFLEN or BUFLEN.

>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 bytes? 
> 
> The output is truncated since the current buffer size is too small 
> (e.g., 2000 < 2014).

Ah sorry - I'd missed that aspect of vsnprintf. We're calling:

  102     int written = os::vsnprintf(buffer, buflen, format, ap);

but it isn't "written" when it exceeds buflen, it's the required buffer 
size.

David
-----

> 
>> Do we have a bug in os::vsnprintf?
> 
> I don't think so.
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
> 
> [2] 
> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
> 
> 
> 

From per.liden at oracle.com  Mon Sep 16 10:14:29 2019
From: per.liden at oracle.com (Per Liden)
Date: Mon, 16 Sep 2019 12:14:29 +0200
Subject: RFR: 8231051: Remove check_obj_alignment() and replace with
 is_object_aligned()
Message-ID: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>

We have a check_obj_alignment() function in oopsHierarchy.hpp. This 
function can be removed and the calls to it can be replaced by calls the 
more common is_object_aligned(), which does the same thing.

Bug: https://bugs.openjdk.java.net/browse/JDK-8231051
Webrev: http://cr.openjdk.java.net/~pliden/8231051/webrev.0

Testing: Currently running though tier-1

/Per

From shade at redhat.com  Mon Sep 16 10:19:51 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2019 12:19:51 +0200
Subject: RFR: 8231051: Remove check_obj_alignment() and replace with
 is_object_aligned()
In-Reply-To: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
References: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
Message-ID: <ddd78d20-b6e6-7144-3c47-e43bbbbd07dd@redhat.com>

On 9/16/19 12:14 PM, Per Liden wrote:
> We have a check_obj_alignment() function in oopsHierarchy.hpp. This function can be removed and the
> calls to it can be replaced by calls the more common is_object_aligned(), which does the same thing.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231051
> Webrev: http://cr.openjdk.java.net/~pliden/8231051/webrev.0

Looks fine to me.

-- 
Thanks,
-Aleksey


From per.liden at oracle.com  Mon Sep 16 10:20:42 2019
From: per.liden at oracle.com (Per Liden)
Date: Mon, 16 Sep 2019 12:20:42 +0200
Subject: RFR: 8231051: Remove check_obj_alignment() and replace with
 is_object_aligned()
In-Reply-To: <ddd78d20-b6e6-7144-3c47-e43bbbbd07dd@redhat.com>
References: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
 <ddd78d20-b6e6-7144-3c47-e43bbbbd07dd@redhat.com>
Message-ID: <37ed767e-d21c-13aa-d87f-e55d7c001146@oracle.com>

Thanks Aleksey!

/Per

On 9/16/19 12:19 PM, Aleksey Shipilev wrote:
> On 9/16/19 12:14 PM, Per Liden wrote:
>> We have a check_obj_alignment() function in oopsHierarchy.hpp. This function can be removed and the
>> calls to it can be replaced by calls the more common is_object_aligned(), which does the same thing.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231051
>> Webrev: http://cr.openjdk.java.net/~pliden/8231051/webrev.0
> 
> Looks fine to me.
> 

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 13:04:09 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 16 Sep 2019 15:04:09 +0200
Subject: PrintAssembly at runtime / to different target
Message-ID: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>

Hi folks,

the PrintAssembly option is of course a valuable tool for a serious Java
developer. I can live with the fact that it requires a debug build of the
JDK (just made one). I understand that all the symbols need some space.

However, what I would really like is a way to selectively enable
PrintAssembly at runtime, from within the JVM. Also, it would be great to
get the output in a buffer, not just on STDOUT. As it is, the disassembly
actually mixes in with whatever the program prints, sometimes on the same
line.

PrintAssembly is so good, but very hampered by the way it is currently
wired.

Anything on the horizon there?

Thanks,
Stefan


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From shade at redhat.com  Mon Sep 16 13:15:24 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2019 15:15:24 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
Message-ID: <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>

On 9/16/19 3:04 PM, Stefan Reich wrote:
> the PrintAssembly option is of course a valuable tool for a serious Java
> developer. I can live with the fact that it requires a debug build of the
> JDK (just made one). 

You don't need debug build. You need hsdis to disassemble the code, which works both fastdebug and
release modes. In fact, the generated code in fast/slowdebug mode can be different, because it may
include calls to debugging facilities.

> However, what I would really like is a way to selectively enable
> PrintAssembly at runtime, from within the JVM.

You can enable it selectively with -XX:CompileCommand=...; that said, in many cases interesting
methods are inlined into larger ones, and you can miss some interesting cases with selective filters.

 > Also, it would be great to
> get the output in a buffer, not just on STDOUT. As it is, the disassembly
> actually mixes in with whatever the program prints, sometimes on the same
> line.

-XX:LogCompilation is your friend here. I don't think you can enable it at runtime, but it
definitely solves dumping the assembly data to stdout. In any case, assembly is printed during code
compilation, so even if you are able to turn it on in runtime, you might already be too late for the
dump.

This is actually written here:
  https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly

-- 
Thanks,
-Aleksey


From thomas.schatzl at oracle.com  Mon Sep 16 13:55:22 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 16 Sep 2019 15:55:22 +0200
Subject: RFR: 8231051: Remove check_obj_alignment() and replace with
 is_object_aligned()
In-Reply-To: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
References: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
Message-ID: <e7d1f990503006ec9f9a11ca8a0b820611a1186e.camel@oracle.com>

Hi,

On Mon, 2019-09-16 at 12:14 +0200, Per Liden wrote:
> We have a check_obj_alignment() function in oopsHierarchy.hpp. This 
> function can be removed and the calls to it can be replaced by calls
> the 
> more common is_object_aligned(), which does the same thing.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231051
> Webrev: http://cr.openjdk.java.net/~pliden/8231051/webrev.0
> 
> Testing: Currently running though tier-1
> 
> /Per

  looks good.

Thomas



From per.liden at oracle.com  Mon Sep 16 13:58:33 2019
From: per.liden at oracle.com (Per Liden)
Date: Mon, 16 Sep 2019 15:58:33 +0200
Subject: RFR: 8231051: Remove check_obj_alignment() and replace with
 is_object_aligned()
In-Reply-To: <e7d1f990503006ec9f9a11ca8a0b820611a1186e.camel@oracle.com>
References: <ee6e8b32-7a9b-b548-336a-985c14e634e3@oracle.com>
 <e7d1f990503006ec9f9a11ca8a0b820611a1186e.camel@oracle.com>
Message-ID: <0B6DE09B-17BE-48C7-BBDB-B1CE9314AACF@oracle.com>

Thanks Thomas!

/Per

> On 16 Sep 2019, at 15:55, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
>> On Mon, 2019-09-16 at 12:14 +0200, Per Liden wrote:
>> We have a check_obj_alignment() function in oopsHierarchy.hpp. This 
>> function can be removed and the calls to it can be replaced by calls
>> the 
>> more common is_object_aligned(), which does the same thing.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231051
>> Webrev: http://cr.openjdk.java.net/~pliden/8231051/webrev.0
>> 
>> Testing: Currently running though tier-1
>> 
>> /Per
> 
>  looks good.
> 
> Thomas
> 
> 

From tobias.hartmann at oracle.com  Mon Sep 16 14:19:35 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 16 Sep 2019 16:19:35 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >= 0)
 failed: offset for non comment?
Message-ID: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>

Hi,

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

I've accidentally broke CodeStrings::find_last with my patch for JDK-8224624 [1] but didn't notice
because the failure only triggers with -XX:+VerifyOops and apparently we don't have any tests that
execute with that flag.

The problem is that CodeString::offset() should only be called for comments. I've modified the
condition accordingly. I've verified that the behavior is now equivalent to before JDK-8224624.

Thanks,
Tobias

[1] https://bugs.openjdk.java.net/browse/JDK-8224624
http://cr.openjdk.java.net/~thartmann/8224624/webrev.00/src/hotspot/share/asm/codeBuffer.cpp.sdiff.html

From patricio.chilano.mateo at oracle.com  Mon Sep 16 15:29:10 2019
From: patricio.chilano.mateo at oracle.com (Patricio Chilano)
Date: Mon, 16 Sep 2019 12:29:10 -0300
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
Message-ID: <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>

Hi Robbin,

Changes look good to me. Thanks for the fixes!

Patricio
On 9/12/19 8:21 AM, Robbin Ehn wrote:
> Hi, here is v3, addressing Patricio's and Dan's review comments.
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>
> Passed t1-5, doing some more testing also.
>
> Thanks, Robbin
>
> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>> Hi, hotspot-dev was the intended list.
>>
>> Thanks, Robbin
>>
>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>> Hi all, please consider,
>>>
>>> To get away from the issues of us revoking in the handshake, but 
>>> before deopt
>>> the locks get re-biased before we hit deopt handler, we instead 
>>> revoke in deopt
>>> handler.
>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>> revoke after
>>> that but before we start looking at the monitors, with a 
>>> NoSafepointVerifier.
>>>
>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>> merge conflicts
>>> some pieces did not apply:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>
>>> So this is what was reviewed.
>>>
>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>
>>> Bug 8224795 fix is here:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>
>>>
>>> After this we have the same functionally as the reverted change-set.
>>>
>>> Here is the changes for doing the revoke in deopt handler instead:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>
>>>
>>> This code was messy adding the deopt revocation in 3 places made it 
>>> worse.
>>> Here is a refactoring of that code. (also removed a dead method in 
>>> biasedlocking):
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>
>>> And here is full:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>
>>> Also a full squashed patch file:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>
>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX 
>>> still
>>> running.
>>>
>>> Thanks, Robbin
>>>
>>>


From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 16:18:09 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 16 Sep 2019 18:18:09 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
Message-ID: <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>

Hi Aleksey!

> -XX:LogCompilation is your friend here.

How can I get assembly output in hotspot.log though? I only ever see it on
STDOUT, even with LogCompilation enabled.

On Mon, Sep 16, 2019, 15:15 Aleksey Shipilev <shade at redhat.com> wrote:

> On 9/16/19 3:04 PM, Stefan Reich wrote:
> > the PrintAssembly option is of course a valuable tool for a serious Java
> > developer. I can live with the fact that it requires a debug build of the
> > JDK (just made one).
>
> You don't need debug build. You need hsdis to disassemble the code, which
> works both fastdebug and
> release modes. In fact, the generated code in fast/slowdebug mode can be
> different, because it may
> include calls to debugging facilities.
>
> > However, what I would really like is a way to selectively enable
> > PrintAssembly at runtime, from within the JVM.
>
> You can enable it selectively with -XX:CompileCommand=...; that said, in
> many cases interesting
> methods are inlined into larger ones, and you can miss some interesting
> cases with selective filters.
>
>  > Also, it would be great to
> > get the output in a buffer, not just on STDOUT. As it is, the disassembly
> > actually mixes in with whatever the program prints, sometimes on the same
> > line.
>
> -XX:LogCompilation is your friend here. I don't think you can enable it at
> runtime, but it
> definitely solves dumping the assembly data to stdout. In any case,
> assembly is printed during code
> compilation, so even if you are able to turn it on in runtime, you might
> already be too late for the
> dump.
>
> This is actually written here:
>   https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly
>
> --
> Thanks,
> -Aleksey
>
>

From shade at redhat.com  Mon Sep 16 16:24:43 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 16 Sep 2019 18:24:43 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
 <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
Message-ID: <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>

On 9/16/19 6:18 PM, Stefan Reich wrote:
> How can I get assembly output in hotspot.log though? I only ever see it on STDOUT, even with
> LogCompilation enabled.

LogCompilation has to include output that would otherwise would end up on tty. It would be captured
in <tty> there.

JMH -prof perfasm does use LogCompilation to get disassembly like this:
 http://hg.openjdk.java.net/code-tools/jmh/file/99d7b73cf1e3/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#l239

-- 
Thanks,
-Aleksey


From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 16:31:43 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 16 Sep 2019 18:31:43 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
 <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
 <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>
Message-ID: <CAC2-jLH8=SzHwUpmg34Bqoe-SaNsWM31tWpfgWxP-tN08haiTQ@mail.gmail.com>

Hmm. I built JDK 13 from Mercurial with fastdebug, and it always sends
assembly output to tty.

root at vmd41736:~/dev/ii-assembly# java13-dbg -version
openjdk version "13-internal" 2019-09-17
OpenJDK Runtime Environment (fastdebug build 13-internal+0-adhoc.root.jdk13)
OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
mixed mode)
root at vmd41736:~/dev/ii-assembly# java13-dbg -XX:+UnlockDiagnosticVMOptions
-XX:+LogCompilation -XX:+PrintAssembly -jar ~/.javax/x30.jar -noawt 1025248
>ii-assembly.out
OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
DebugNonSafepoints to gain additional output
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
method java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of x30
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
root at vmd41736:~/dev/ii-assembly# java13-dbg -XX:+UnlockDiagnosticVMOptions
-XX:+LogCompilation -XX:+PrintAssembly -jar ~/.javax/x30.jar -noawt 1025248
>hotspot.out
OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
DebugNonSafepoints to gain additional output
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
method java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of x30
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
root at vmd41736:~/dev/ii-assembly# ls -ltrh
total 184M
-rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
-rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
hotspot_pid15548.log|head -5
hotspot.out: ;; move 0 -> 2
hotspot.out:000     movl    rscratch1, [j_rarg0 +
oopDesc::klass_offset_in_bytes()] # compressed klass
hotspot.out: movq    rscratch1, poll_offset[r15_thread]
#polling_page_address
hotspot.out:000     movl    rscratch1, [j_rarg0 +
oopDesc::klass_offset_in_bytes()] # compressed klass
hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
java/lang/String.coder (constant)

On Mon, 16 Sep 2019 at 18:24, Aleksey Shipilev <shade at redhat.com> wrote:

> On 9/16/19 6:18 PM, Stefan Reich wrote:
> > How can I get assembly output in hotspot.log though? I only ever see it
> on STDOUT, even with
> > LogCompilation enabled.
>
> LogCompilation has to include output that would otherwise would end up on
> tty. It would be captured
> in <tty> there.
>
> JMH -prof perfasm does use LogCompilation to get disassembly like this:
>
> http://hg.openjdk.java.net/code-tools/jmh/file/99d7b73cf1e3/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#l239
>
> --
> Thanks,
> -Aleksey
>
>

-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 16:33:35 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 16 Sep 2019 18:33:35 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <CAC2-jLH8=SzHwUpmg34Bqoe-SaNsWM31tWpfgWxP-tN08haiTQ@mail.gmail.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
 <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
 <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>
 <CAC2-jLH8=SzHwUpmg34Bqoe-SaNsWM31tWpfgWxP-tN08haiTQ@mail.gmail.com>
Message-ID: <CAC2-jLG19d=Ltc8Yp1d6wXo+EavHEp_xc8YZ0VE_an9nankxPA@mail.gmail.com>

Oops, too many lines copied, please ignore. This is the actual log:

root at vmd41736:~/dev/ii-assembly# java13-dbg -version
openjdk version "13-internal" 2019-09-17
OpenJDK Runtime Environment (fastdebug build 13-internal+0-adhoc.root.jdk13)
OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
mixed mode)
root at vmd41736:~/dev/ii-assembly# java13-dbg -XX:+UnlockDiagnosticVMOptions
-XX:+LogCompilation -XX:+PrintAssembly -jar ~/.javax/x30.jar -noawt 1025248
>hotspot.out
OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
DebugNonSafepoints to gain additional output
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
method java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of x30
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
root at vmd41736:~/dev/ii-assembly# ls -ltrh
total 184M
-rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
-rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
hotspot_pid15548.log|head -5
hotspot.out: ;; move 0 -> 2
hotspot.out:000     movl    rscratch1, [j_rarg0 +
oopDesc::klass_offset_in_bytes()]
# compressed klass
hotspot.out: movq    rscratch1, poll_offset[r15_thread]
#polling_page_address
hotspot.out:000     movl    rscratch1, [j_rarg0 +
oopDesc::klass_offset_in_bytes()]
# compressed klass
hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
java/lang/String.coder (constant)

On Mon, 16 Sep 2019 at 18:31, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hmm. I built JDK 13 from Mercurial with fastdebug, and it always sends
> assembly output to tty.
>
> root at vmd41736:~/dev/ii-assembly# java13-dbg -version
> openjdk version "13-internal" 2019-09-17
> OpenJDK Runtime Environment (fastdebug build
> 13-internal+0-adhoc.root.jdk13)
> OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
> mixed mode)
> root at vmd41736:~/dev/ii-assembly# java13-dbg
> -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly -jar
> ~/.javax/x30.jar -noawt 1025248 >ii-assembly.out
> OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
> DebugNonSafepoints to gain additional output
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
> method java.lang.Object.registerNatives()
> WARNING: Please consider reporting this to the maintainers of x30
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> root at vmd41736:~/dev/ii-assembly# java13-dbg
> -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly -jar
> ~/.javax/x30.jar -noawt 1025248 >hotspot.out
> OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
> DebugNonSafepoints to gain additional output
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
> method java.lang.Object.registerNatives()
> WARNING: Please consider reporting this to the maintainers of x30
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> root at vmd41736:~/dev/ii-assembly# ls -ltrh
> total 184M
> -rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
> -rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
> root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
> hotspot_pid15548.log|head -5
> hotspot.out: ;; move 0 -> 2
> hotspot.out:000     movl    rscratch1, [j_rarg0 +
> oopDesc::klass_offset_in_bytes()] # compressed klass
> hotspot.out: movq    rscratch1, poll_offset[r15_thread]
> #polling_page_address
> hotspot.out:000     movl    rscratch1, [j_rarg0 +
> oopDesc::klass_offset_in_bytes()] # compressed klass
> hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
> java/lang/String.coder (constant)
>
> On Mon, 16 Sep 2019 at 18:24, Aleksey Shipilev <shade at redhat.com> wrote:
>
>> On 9/16/19 6:18 PM, Stefan Reich wrote:
>> > How can I get assembly output in hotspot.log though? I only ever see it
>> on STDOUT, even with
>> > LogCompilation enabled.
>>
>> LogCompilation has to include output that would otherwise would end up on
>> tty. It would be captured
>> in <tty> there.
>>
>> JMH -prof perfasm does use LogCompilation to get disassembly like this:
>>
>> http://hg.openjdk.java.net/code-tools/jmh/file/99d7b73cf1e3/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#l239
>>
>> --
>> Thanks,
>> -Aleksey
>>
>>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From daniel.daugherty at oracle.com  Mon Sep 16 16:43:33 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Sep 2019 12:43:33 -0400
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
 <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>
Message-ID: <853c17a2-beec-46b4-2fa3-5f8dd321aba5@oracle.com>

Looks good to me also.

Dan


On 9/16/19 11:29 AM, Patricio Chilano wrote:
> Hi Robbin,
>
> Changes look good to me. Thanks for the fixes!
>
> Patricio
> On 9/12/19 8:21 AM, Robbin Ehn wrote:
>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>
>> Passed t1-5, doing some more testing also.
>>
>> Thanks, Robbin
>>
>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>> Hi, hotspot-dev was the intended list.
>>>
>>> Thanks, Robbin
>>>
>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>> Hi all, please consider,
>>>>
>>>> To get away from the issues of us revoking in the handshake, but 
>>>> before deopt
>>>> the locks get re-biased before we hit deopt handler, we instead 
>>>> revoke in deopt
>>>> handler.
>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>>> revoke after
>>>> that but before we start looking at the monitors, with a 
>>>> NoSafepointVerifier.
>>>>
>>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>>> merge conflicts
>>>> some pieces did not apply:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>>
>>>> So this is what was reviewed.
>>>>
>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>
>>>> Bug 8224795 fix is here:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>>
>>>>
>>>> After this we have the same functionally as the reverted change-set.
>>>>
>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>>
>>>>
>>>> This code was messy adding the deopt revocation in 3 places made it 
>>>> worse.
>>>> Here is a refactoring of that code. (also removed a dead method in 
>>>> biasedlocking):
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>
>>>> And here is full:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>
>>>> Also a full squashed patch file:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>
>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX 
>>>> still
>>>> running.
>>>>
>>>> Thanks, Robbin
>>>>
>>>>
>


From Sergey.Bylokhov at oracle.com  Mon Sep 16 21:50:19 2019
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Sep 2019 14:50:19 -0700
Subject: [14] Review Request: JDK-8231027 Correct typos
Message-ID: <bef4fd4f-7eb6-4502-710a-d04d6ed9d810@oracle.com>

Hello.
Please review the fix for JDK 14.

Bug: https://bugs.openjdk.java.net/browse/JDK-8231027
Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00

One common typo is fixed across a few components like client, build, and hotspot.

-- 
Best regards, Sergey.

From vitalyd at gmail.com  Mon Sep 16 22:21:47 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 16 Sep 2019 18:21:47 -0400
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <CAC2-jLG19d=Ltc8Yp1d6wXo+EavHEp_xc8YZ0VE_an9nankxPA@mail.gmail.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
 <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
 <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>
 <CAC2-jLH8=SzHwUpmg34Bqoe-SaNsWM31tWpfgWxP-tN08haiTQ@mail.gmail.com>
 <CAC2-jLG19d=Ltc8Yp1d6wXo+EavHEp_xc8YZ0VE_an9nankxPA@mail.gmail.com>
Message-ID: <CAHjP37E2vnNBboLh=hhg2WUk9br4n+9H7S0p5nLiw6Nw2DZebg@mail.gmail.com>

What if you specify -XX:LogFile=/path/to/file? It should then send output
there.

On Mon, Sep 16, 2019 at 12:35 PM Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Oops, too many lines copied, please ignore. This is the actual log:
>
> root at vmd41736:~/dev/ii-assembly# java13-dbg -version
> openjdk version "13-internal" 2019-09-17
> OpenJDK Runtime Environment (fastdebug build
> 13-internal+0-adhoc.root.jdk13)
> OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
> mixed mode)
> root at vmd41736:~/dev/ii-assembly# java13-dbg -XX:+UnlockDiagnosticVMOptions
> -XX:+LogCompilation -XX:+PrintAssembly -jar ~/.javax/x30.jar -noawt 1025248
> >hotspot.out
> OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
> DebugNonSafepoints to gain additional output
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
> method java.lang.Object.registerNatives()
> WARNING: Please consider reporting this to the maintainers of x30
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> root at vmd41736:~/dev/ii-assembly# ls -ltrh
> total 184M
> -rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
> -rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
> root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
> hotspot_pid15548.log|head -5
> hotspot.out: ;; move 0 -> 2
> hotspot.out:000     movl    rscratch1, [j_rarg0 +
> oopDesc::klass_offset_in_bytes()]
> # compressed klass
> hotspot.out: movq    rscratch1, poll_offset[r15_thread]
> #polling_page_address
> hotspot.out:000     movl    rscratch1, [j_rarg0 +
> oopDesc::klass_offset_in_bytes()]
> # compressed klass
> hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
> java/lang/String.coder (constant)
>
> On Mon, 16 Sep 2019 at 18:31, Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
> > Hmm. I built JDK 13 from Mercurial with fastdebug, and it always sends
> > assembly output to tty.
> >
> > root at vmd41736:~/dev/ii-assembly# java13-dbg -version
> > openjdk version "13-internal" 2019-09-17
> > OpenJDK Runtime Environment (fastdebug build
> > 13-internal+0-adhoc.root.jdk13)
> > OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
> > mixed mode)
> > root at vmd41736:~/dev/ii-assembly# java13-dbg
> > -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly
> -jar
> > ~/.javax/x30.jar -noawt 1025248 >ii-assembly.out
> > OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
> > DebugNonSafepoints to gain additional output
> > WARNING: An illegal reflective access operation has occurred
> > WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
> > method java.lang.Object.registerNatives()
> > WARNING: Please consider reporting this to the maintainers of x30
> > WARNING: Use --illegal-access=warn to enable warnings of further illegal
> > reflective access operations
> > WARNING: All illegal access operations will be denied in a future release
> > root at vmd41736:~/dev/ii-assembly# java13-dbg
> > -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly
> -jar
> > ~/.javax/x30.jar -noawt 1025248 >hotspot.out
> > OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
> > DebugNonSafepoints to gain additional output
> > WARNING: An illegal reflective access operation has occurred
> > WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
> > method java.lang.Object.registerNatives()
> > WARNING: Please consider reporting this to the maintainers of x30
> > WARNING: Use --illegal-access=warn to enable warnings of further illegal
> > reflective access operations
> > WARNING: All illegal access operations will be denied in a future release
> > root at vmd41736:~/dev/ii-assembly# ls -ltrh
> > total 184M
> > -rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
> > -rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
> > root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
> > hotspot_pid15548.log|head -5
> > hotspot.out: ;; move 0 -> 2
> > hotspot.out:000     movl    rscratch1, [j_rarg0 +
> > oopDesc::klass_offset_in_bytes()] # compressed klass
> > hotspot.out: movq    rscratch1, poll_offset[r15_thread]
> > #polling_page_address
> > hotspot.out:000     movl    rscratch1, [j_rarg0 +
> > oopDesc::klass_offset_in_bytes()] # compressed klass
> > hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
> > java/lang/String.coder (constant)
> >
> > On Mon, 16 Sep 2019 at 18:24, Aleksey Shipilev <shade at redhat.com> wrote:
> >
> >> On 9/16/19 6:18 PM, Stefan Reich wrote:
> >> > How can I get assembly output in hotspot.log though? I only ever see
> it
> >> on STDOUT, even with
> >> > LogCompilation enabled.
> >>
> >> LogCompilation has to include output that would otherwise would end up
> on
> >> tty. It would be captured
> >> in <tty> there.
> >>
> >> JMH -prof perfasm does use LogCompilation to get disassembly like this:
> >>
> >>
> http://hg.openjdk.java.net/code-tools/jmh/file/99d7b73cf1e3/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#l239
> >>
> >> --
> >> Thanks,
> >> -Aleksey
> >>
> >>
> >
> > --
> > Stefan Reich
> > BotCompany.de // Java-based operating systems
> >
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>
-- 
Sent from my phone

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 22:29:58 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 17 Sep 2019 00:29:58 +0200
Subject: PrintAssembly at runtime / to different target
In-Reply-To: <CAHjP37E2vnNBboLh=hhg2WUk9br4n+9H7S0p5nLiw6Nw2DZebg@mail.gmail.com>
References: <CAC2-jLHogo=kEPNwHgmitdwdMWvHPW7zb_AmUH2H8c7mYE7WDA@mail.gmail.com>
 <bc9ab064-76a5-8b57-d8ec-852afee890d5@redhat.com>
 <CAC2-jLERw-6ZnBuDjJ0EYOB1LeoWAktz3OcmgZQECNV0YHwuSQ@mail.gmail.com>
 <68066fb6-ccf4-1f4c-4450-f9018ef1ca8d@redhat.com>
 <CAC2-jLH8=SzHwUpmg34Bqoe-SaNsWM31tWpfgWxP-tN08haiTQ@mail.gmail.com>
 <CAC2-jLG19d=Ltc8Yp1d6wXo+EavHEp_xc8YZ0VE_an9nankxPA@mail.gmail.com>
 <CAHjP37E2vnNBboLh=hhg2WUk9br4n+9H7S0p5nLiw6Nw2DZebg@mail.gmail.com>
Message-ID: <CAC2-jLEBY_rBWdNydQJY6sunv4Vg+NX74SRp1cFfZ0Xq2WNH4Q@mail.gmail.com>

Oh, now it seems to work, thanks. It does print the assembly BOTH on STDOUT
and in the XML log file. What's this affiliation the JVM has with STDOUT? :D

~/dev/jdk-13-src/jdk13/build/linux-x86_64-server-fastdebug/jdk/bin/java \
  -XX:+UnlockDiagnosticVMOptions \
  -XX:+PrintAssembly -XX:PrintAssemblyOptions=intel \
  -XX:LogFile=the.log \
  -cp ../javacpp.jar:. Dot >hotspot-intel.out

On Tue, 17 Sep 2019 at 00:21, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> What if you specify -XX:LogFile=/path/to/file? It should then send output
> there.
>
> On Mon, Sep 16, 2019 at 12:35 PM Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Oops, too many lines copied, please ignore. This is the actual log:
>>
>> root at vmd41736:~/dev/ii-assembly# java13-dbg -version
>> openjdk version "13-internal" 2019-09-17
>> OpenJDK Runtime Environment (fastdebug build
>> 13-internal+0-adhoc.root.jdk13)
>> OpenJDK 64-Bit Server VM (fastdebug build 13-internal+0-adhoc.root.jdk13,
>> mixed mode)
>> root at vmd41736:~/dev/ii-assembly# java13-dbg
>> -XX:+UnlockDiagnosticVMOptions
>> -XX:+LogCompilation -XX:+PrintAssembly -jar ~/.javax/x30.jar -noawt
>> 1025248
>> >hotspot.out
>> OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
>> DebugNonSafepoints to gain additional output
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
>> method java.lang.Object.registerNatives()
>> WARNING: Please consider reporting this to the maintainers of x30
>> WARNING: Use --illegal-access=warn to enable warnings of further illegal
>> reflective access operations
>> WARNING: All illegal access operations will be denied in a future release
>> root at vmd41736:~/dev/ii-assembly# ls -ltrh
>> total 184M
>> -rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
>> -rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
>> root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
>> hotspot_pid15548.log|head -5
>> hotspot.out: ;; move 0 -> 2
>> hotspot.out:000     movl    rscratch1, [j_rarg0 +
>> oopDesc::klass_offset_in_bytes()]
>> # compressed klass
>> hotspot.out: movq    rscratch1, poll_offset[r15_thread]
>> #polling_page_address
>> hotspot.out:000     movl    rscratch1, [j_rarg0 +
>> oopDesc::klass_offset_in_bytes()]
>> # compressed klass
>> hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
>> java/lang/String.coder (constant)
>>
>> On Mon, 16 Sep 2019 at 18:31, Stefan Reich <
>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>
>> > Hmm. I built JDK 13 from Mercurial with fastdebug, and it always sends
>> > assembly output to tty.
>> >
>> > root at vmd41736:~/dev/ii-assembly# java13-dbg -version
>> > openjdk version "13-internal" 2019-09-17
>> > OpenJDK Runtime Environment (fastdebug build
>> > 13-internal+0-adhoc.root.jdk13)
>> > OpenJDK 64-Bit Server VM (fastdebug build
>> 13-internal+0-adhoc.root.jdk13,
>> > mixed mode)
>> > root at vmd41736:~/dev/ii-assembly# java13-dbg
>> > -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly
>> -jar
>> > ~/.javax/x30.jar -noawt 1025248 >ii-assembly.out
>> > OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
>> > DebugNonSafepoints to gain additional output
>> > WARNING: An illegal reflective access operation has occurred
>> > WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
>> > method java.lang.Object.registerNatives()
>> > WARNING: Please consider reporting this to the maintainers of x30
>> > WARNING: Use --illegal-access=warn to enable warnings of further illegal
>> > reflective access operations
>> > WARNING: All illegal access operations will be denied in a future
>> release
>> > root at vmd41736:~/dev/ii-assembly# java13-dbg
>> > -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:+PrintAssembly
>> -jar
>> > ~/.javax/x30.jar -noawt 1025248 >hotspot.out
>> > OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on
>> > DebugNonSafepoints to gain additional output
>> > WARNING: An illegal reflective access operation has occurred
>> > WARNING: Illegal reflective access by x30 (file:/root/.javax/x30.jar) to
>> > method java.lang.Object.registerNatives()
>> > WARNING: Please consider reporting this to the maintainers of x30
>> > WARNING: Use --illegal-access=warn to enable warnings of further illegal
>> > reflective access operations
>> > WARNING: All illegal access operations will be denied in a future
>> release
>> > root at vmd41736:~/dev/ii-assembly# ls -ltrh
>> > total 184M
>> > -rw-r--r-- 1 root root  42M Sep 16 18:26 hotspot.out
>> > -rw-r--r-- 1 root root  46M Sep 16 18:26 hotspot_pid15548.log
>> > root at vmd41736:~/dev/ii-assembly# grep mov hotspot.out
>> > hotspot_pid15548.log|head -5
>> > hotspot.out: ;; move 0 -> 2
>> > hotspot.out:000     movl    rscratch1, [j_rarg0 +
>> > oopDesc::klass_offset_in_bytes()] # compressed klass
>> > hotspot.out: movq    rscratch1, poll_offset[r15_thread]
>> > #polling_page_address
>> > hotspot.out:000     movl    rscratch1, [j_rarg0 +
>> > oopDesc::klass_offset_in_bytes()] # compressed klass
>> > hotspot.out:02c     movsbl  R10, [RSI + #20 (8-bit)] # byte ! Field:
>> > java/lang/String.coder (constant)
>> >
>> > On Mon, 16 Sep 2019 at 18:24, Aleksey Shipilev <shade at redhat.com>
>> wrote:
>> >
>> >> On 9/16/19 6:18 PM, Stefan Reich wrote:
>> >> > How can I get assembly output in hotspot.log though? I only ever see
>> it
>> >> on STDOUT, even with
>> >> > LogCompilation enabled.
>> >>
>> >> LogCompilation has to include output that would otherwise would end up
>> on
>> >> tty. It would be captured
>> >> in <tty> there.
>> >>
>> >> JMH -prof perfasm does use LogCompilation to get disassembly like this:
>> >>
>> >>
>> http://hg.openjdk.java.net/code-tools/jmh/file/99d7b73cf1e3/jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractPerfAsmProfiler.java#l239
>> >>
>> >> --
>> >> Thanks,
>> >> -Aleksey
>> >>
>> >>
>> >
>> > --
>> > Stefan Reich
>> > BotCompany.de // Java-based operating systems
>> >
>>
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
> --
> Sent from my phone
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 22:34:23 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 17 Sep 2019 00:34:23 +0200
Subject: Does HotSpot ever stop profiling?
Message-ID: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>

Here's another thing I would love to have cleared up.

Once a method is C2-compiled - does it still update its invocation counters?

I would assume counting stops at that point since we have done all we could
for the method. Also the invocation counting overhead is always
embarrassing when fighting some C++ guys over claims on how "slow" Java is.
:o)

OTOH, there might be scenarios where it makes sense to have a second look
at "hot" methods, even if they are C2-compiled. Not sure if that scenario
exists in the current infrastructure.

Which one is it in reality?

-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From david.holmes at oracle.com  Mon Sep 16 22:38:26 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2019 08:38:26 +1000
Subject: [14] Review Request: JDK-8231027 Correct typos
In-Reply-To: <bef4fd4f-7eb6-4502-710a-d04d6ed9d810@oracle.com>
References: <bef4fd4f-7eb6-4502-710a-d04d6ed9d810@oracle.com>
Message-ID: <126806ec-a1d8-9bce-b5d0-b18d9f8f993f@oracle.com>

Hi Sergey,

These changes are all fine and trivial.

Thanks,
David

On 17/09/2019 7:50 am, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 14.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231027
> Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00
> 
> One common typo is fixed across a few components like client, build, and 
> hotspot.
> 

From vitalyd at gmail.com  Mon Sep 16 22:47:39 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 16 Sep 2019 18:47:39 -0400
Subject: Does HotSpot ever stop profiling?
In-Reply-To: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
References: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
Message-ID: <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>

On Mon, Sep 16, 2019 at 6:35 PM Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Here's another thing I would love to have cleared up.
>
> Once a method is C2-compiled - does it still update its invocation
> counters?

Nope.  C2 compiled methods run profile-free.  There can be certain events
that trigger a deopt that will toss out the C2 method (with future C2
compilations off newly collected profiling possible), but it won?t be
counter based.

>
>
> I would assume counting stops at that point since we have done all we could
> for the method. Also the invocation counting overhead is always
> embarrassing when fighting some C++ guys over claims on how "slow" Java is.
> :o)
>
> OTOH, there might be scenarios where it makes sense to have a second look
> at "hot" methods, even if they are C2-compiled. Not sure if that scenario
> exists in the current infrastructure.

That infrastructure is called a process restart :) j/k.  There?re some
compiler control APIs, but they?re mostly to allow JIT testing (AFAIK).  I
think it allows manually marking a C2 method for reclaim (ie not entrant),
but I don?t recall the details offhand.

>
>
> Which one is it in reality?
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>
-- 
Sent from my phone

From david.holmes at oracle.com  Mon Sep 16 22:50:33 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2019 08:50:33 +1000
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
In-Reply-To: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
References: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
Message-ID: <545a82fb-416b-7318-2772-ca0d8198f2be@oracle.com>

ping!

Thanks,
David

On 13/09/2019 7:12 pm, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8230424/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8230424
> 
> The next instalment of the interruption logic refactoring.
> 
> Summary of changes:
> - the windows-specific actions in os:interrupt and os::is_interrupted 
> are pushed down into the windows-specific osThread code. This all 
> relates to the only-used-by-the-JDK _interrupt_event.
> - the POSIX variant of os::interrupt and os::is_interrupted is inlined 
> as platform-independent code in the Thread versions and those versions 
> are themselves moved to JavaThread as instance methods.
> - minor cleanups to the logic of interrupt() as we can never have NULL 
> events as we are always guaranteed to be operating on a live thread.
> - All call sites adjusted as needed.
> 
> One minor wart in this refactor is that on Windows we will execute an 
> OrderAccess::release() after setting the interrupt state in the platform 
> code, and then execute an additional fence() in the shared code. I don't 
> think this is worth trying to "fix" - and hopefully if we can get rid of 
> the Windows _interrupt_event this will all go away.
> 
> If you are wondering why Windows used OrderAccess::release while POSIX 
> used OrderAccess::fence, I have no idea, and I do not intend to change 
> either of them. The only safe change would be to use fence() in both 
> cases, which just makes the Windows wart worse - and unnecessarily so as 
> we have seen no bugs using the existing release().
> 
> Testing:
>  ?- hotspot runtime
>  ?- Tiers 1-3
> 
> Thanks,
> David

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 23:05:24 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 17 Sep 2019 01:05:24 +0200
Subject: Does HotSpot ever stop profiling?
In-Reply-To: <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>
References: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
 <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>
Message-ID: <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>

Hey, thanks for your answer.

So a method is normally only once C2-compiled. How does inlining fit into
the picture? You start from the method body and inline as deeply as
possible?

I always thought a method would be compiled multiple times while improving
its inlining. But maybe that makes no sense and you can do it all in a
single compilation effort.


On Tue, 17 Sep 2019 at 00:47, Vitaly Davidovich <vitalyd at gmail.com> wrote:

>
>
> On Mon, Sep 16, 2019 at 6:35 PM Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Here's another thing I would love to have cleared up.
>>
>> Once a method is C2-compiled - does it still update its invocation
>> counters?
>
> Nope.  C2 compiled methods run profile-free.  There can be certain events
> that trigger a deopt that will toss out the C2 method (with future C2
> compilations off newly collected profiling possible), but it won?t be
> counter based.
>
>>
>>
>> I would assume counting stops at that point since we have done all we
>> could
>> for the method. Also the invocation counting overhead is always
>> embarrassing when fighting some C++ guys over claims on how "slow" Java
>> is.
>> :o)
>>
>> OTOH, there might be scenarios where it makes sense to have a second look
>> at "hot" methods, even if they are C2-compiled. Not sure if that scenario
>> exists in the current infrastructure.
>
> That infrastructure is called a process restart :) j/k.  There?re some
> compiler control APIs, but they?re mostly to allow JIT testing (AFAIK).  I
> think it allows manually marking a C2 method for reclaim (ie not entrant),
> but I don?t recall the details offhand.
>
>>
>>
>> Which one is it in reality?
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
> --
> Sent from my phone
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From vitalyd at gmail.com  Mon Sep 16 23:16:57 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 16 Sep 2019 19:16:57 -0400
Subject: Does HotSpot ever stop profiling?
In-Reply-To: <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>
References: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
 <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>
 <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>
Message-ID: <CAHjP37EYMCKHmvggGh6FOWiHxMKcoDQxXZg2gZpJgDO+9czT5g@mail.gmail.com>

On Mon, Sep 16, 2019 at 7:05 PM Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> Hey, thanks for your answer.
>
> So a method is normally only once C2-compiled. How does inlining fit into
> the picture? You start from the method body and inline as deeply as
> possible?
>
So saying a given method is only once compiled by C2 is slightly
misleading.  What C2 compiles is actually a tree of methods.  I?m going to
simplify a bit, but a method that reaches C2 compilation threshold is
queued up for a C2 compile.  That method serves as the root of the
compilation tree.  Callees in that method can be inlined as well, based on
profiling info + a bunch of heuristics.  So you can end up with some leaf
methods inljmed and compiled in multiple call graphs.  But there are also
cases where C2 will refuse to inline a method that?s already been compiled
if its resulting machine code size is over a (tunable) threshold - that?s
just 1 of the different heuristics :).

But the main point I wanted to convey is that once that blob is compiled by
C2, that blob has no counters and generally sticks around (modulo
traps/deopt or code cache pressure or some such).

>
> I always thought a method would be compiled multiple times while improving
> its inlining. But maybe that makes no sense and you can do it all in a
> single compilation effort.
>
>
> On Tue, 17 Sep 2019 at 00:47, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 16, 2019 at 6:35 PM Stefan Reich <
>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>
>>> Here's another thing I would love to have cleared up.
>>>
>>> Once a method is C2-compiled - does it still update its invocation
>>> counters?
>>
>> Nope.  C2 compiled methods run profile-free.  There can be certain events
>> that trigger a deopt that will toss out the C2 method (with future C2
>> compilations off newly collected profiling possible), but it won?t be
>> counter based.
>>
>>>
>>>
>>> I would assume counting stops at that point since we have done all we
>>> could
>>> for the method. Also the invocation counting overhead is always
>>> embarrassing when fighting some C++ guys over claims on how "slow" Java
>>> is.
>>> :o)
>>>
>>> OTOH, there might be scenarios where it makes sense to have a second look
>>> at "hot" methods, even if they are C2-compiled. Not sure if that scenario
>>> exists in the current infrastructure.
>>
>> That infrastructure is called a process restart :) j/k.  There?re some
>> compiler control APIs, but they?re mostly to allow JIT testing (AFAIK).  I
>> think it allows manually marking a C2 method for reclaim (ie not entrant),
>> but I don?t recall the details offhand.
>>
>>>
>>>
>>> Which one is it in reality?
>>>
>>> --
>>> Stefan Reich
>>> BotCompany.de // Java-based operating systems
>>>
>> --
>> Sent from my phone
>>
>
>
> --
> Stefan Reich
> BotCompany.de // Java-based operating systems
>
-- 
Sent from my phone

From david.holmes at oracle.com  Mon Sep 16 23:19:48 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2019 09:19:48 +1000
Subject: Does HotSpot ever stop profiling?
In-Reply-To: <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>
References: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
 <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>
 <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>
Message-ID: <dccdd8a0-9020-8645-67c3-bfad17568383@oracle.com>

On 17/09/2019 9:05 am, Stefan Reich wrote:
> Hey, thanks for your answer.
> 
> So a method is normally only once C2-compiled. How does inlining fit into
> the picture? You start from the method body and inline as deeply as
> possible?
> 
> I always thought a method would be compiled multiple times while improving
> its inlining. But maybe that makes no sense and you can do it all in a
> single compilation effort.

Not sure how current** it is but there is info on the wiki

https://wiki.openjdk.java.net/display/HotSpot
https://wiki.openjdk.java.net/display/HotSpot/Server+Compiler+Inlining+Messages

** Just because it was written in 2011 doesn't mean it isn't current. :)

David

> 
> On Tue, 17 Sep 2019 at 00:47, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
>>
>>
>> On Mon, Sep 16, 2019 at 6:35 PM Stefan Reich <
>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>
>>> Here's another thing I would love to have cleared up.
>>>
>>> Once a method is C2-compiled - does it still update its invocation
>>> counters?
>>
>> Nope.  C2 compiled methods run profile-free.  There can be certain events
>> that trigger a deopt that will toss out the C2 method (with future C2
>> compilations off newly collected profiling possible), but it won?t be
>> counter based.
>>
>>>
>>>
>>> I would assume counting stops at that point since we have done all we
>>> could
>>> for the method. Also the invocation counting overhead is always
>>> embarrassing when fighting some C++ guys over claims on how "slow" Java
>>> is.
>>> :o)
>>>
>>> OTOH, there might be scenarios where it makes sense to have a second look
>>> at "hot" methods, even if they are C2-compiled. Not sure if that scenario
>>> exists in the current infrastructure.
>>
>> That infrastructure is called a process restart :) j/k.  There?re some
>> compiler control APIs, but they?re mostly to allow JIT testing (AFAIK).  I
>> think it allows manually marking a C2 method for reclaim (ie not entrant),
>> but I don?t recall the details offhand.
>>
>>>
>>>
>>> Which one is it in reality?
>>>
>>> --
>>> Stefan Reich
>>> BotCompany.de // Java-based operating systems
>>>
>> --
>> Sent from my phone
>>
> 
> 

From ioi.lam at oracle.com  Mon Sep 16 23:20:31 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 16 Sep 2019 16:20:31 -0700
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
Message-ID: <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>



On 9/16/19 12:44 AM, David Holmes wrote:
> On 16/09/2019 5:09 pm, Jie Fu wrote:
>> Hi David,
>>
>> Sorry for the confusion.
>
> The confusion is mine, not from you :)
>
>> On 2019/9/16 ??2:40, David Holmes wrote:
>>> Okay I'm confused. I had assumed that the passed in buffer size must 
>>> be different in each case because of the 2014/2032/2050 values in 
>>> the message, but in fact they are all sized at 2000. 
>> According to the source code, the buffer size can be either 
>> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>> So it isn't always 2000.
>
> It is 2000 is all three examples of the output that you gave.

xmlStream::va_tag() uses 2*K.

>
>>> That makes no sense
>> I think it makes sense.
>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be 
>> increased if the current buffer size wasn't printed.
>
> You need to know the original caller that passed in the buffer size.
>
> But we can't just keep increasing the buffer size. We probably need to 
> examine the callers to see what amount of information is trying to be 
> passed through. Then decide whether to adjust what the callers are 
> passing through, or adjust the buffer size - perhaps on a callsite by 
> callsite basis rather than just bumping O_BUFLEN or BUFLEN.
>

I think the message should stop saying "increase O_BUFLEN" -- probably 
the reviewers will reject all future increase of O_BUFLEN and will 
suggest fixing the caller of outputStream::do_vsnprintf instead.

Callers of outputStream::do_vsnprintf don't necessarily use O_BUFLEN. 
E.g., xmlStream::va_tag allocates its own buffer. 
VMError::report_and_die() also uses its own buffer -- it uses O_BUFLEN 
today, but there's no guarantee or requirement that it always does that.

How about saying something like "outputStream::do_vsnprintf output 
truncated -- buffer length is 2000 bytes but 2100 bytes are needed."


>>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 
>>> bytes? 
>>
>> The output is truncated since the current buffer size is too small 
>> (e.g., 2000 < 2014).
>
> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>
> ?102???? int written = os::vsnprintf(buffer, buflen, format, ap);
>
> but it isn't "written" when it exceeds buflen, it's the required 
> buffer size.
>

I think the variable "written" should be renamed to "required".

Thanks
- Ioi

> David
> -----
>
>>
>>> Do we have a bug in os::vsnprintf?
>>
>> I don't think so.
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>
>> [2] 
>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>
>>
>>


From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 16 23:39:13 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Tue, 17 Sep 2019 01:39:13 +0200
Subject: Does HotSpot ever stop profiling?
In-Reply-To: <CAHjP37EYMCKHmvggGh6FOWiHxMKcoDQxXZg2gZpJgDO+9czT5g@mail.gmail.com>
References: <CAC2-jLHaeWJYOc158W-Qt4h_h9YQsULBSZ4rFqOCjWge5gQ5oQ@mail.gmail.com>
 <CAHjP37FELGFUGRefKqbeNEBXBvuFGoOUO=ne5LdsAqUPeASVYg@mail.gmail.com>
 <CAC2-jLF-mMKgB4K07s1jmf2SN-o05W8om_CMtDHX4qdB1_p=aQ@mail.gmail.com>
 <CAHjP37EYMCKHmvggGh6FOWiHxMKcoDQxXZg2gZpJgDO+9czT5g@mail.gmail.com>
Message-ID: <CAC2-jLFH6t8b=t7m2kT=zH86ipCyocSXJHxpgD=SitgJBhgk7g@mail.gmail.com>

OK, that sounds pretty much like what I had imagined. Obviously inlined
methods can appear multiple times in the final code. Thanks

On Tue, 17 Sep 2019 at 01:17, Vitaly Davidovich <vitalyd at gmail.com> wrote:

>
>
> On Mon, Sep 16, 2019 at 7:05 PM Stefan Reich <
> stefan.reich.maker.of.eye at googlemail.com> wrote:
>
>> Hey, thanks for your answer.
>>
>> So a method is normally only once C2-compiled. How does inlining fit into
>> the picture? You start from the method body and inline as deeply as
>> possible?
>>
> So saying a given method is only once compiled by C2 is slightly
> misleading.  What C2 compiles is actually a tree of methods.  I?m going to
> simplify a bit, but a method that reaches C2 compilation threshold is
> queued up for a C2 compile.  That method serves as the root of the
> compilation tree.  Callees in that method can be inlined as well, based on
> profiling info + a bunch of heuristics.  So you can end up with some leaf
> methods inljmed and compiled in multiple call graphs.  But there are also
> cases where C2 will refuse to inline a method that?s already been compiled
> if its resulting machine code size is over a (tunable) threshold - that?s
> just 1 of the different heuristics :).
>
> But the main point I wanted to convey is that once that blob is compiled
> by C2, that blob has no counters and generally sticks around (modulo
> traps/deopt or code cache pressure or some such).
>
>>
>> I always thought a method would be compiled multiple times while
>> improving its inlining. But maybe that makes no sense and you can do it all
>> in a single compilation effort.
>>
>>
>> On Tue, 17 Sep 2019 at 00:47, Vitaly Davidovich <vitalyd at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 16, 2019 at 6:35 PM Stefan Reich <
>>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>>
>>>> Here's another thing I would love to have cleared up.
>>>>
>>>> Once a method is C2-compiled - does it still update its invocation
>>>> counters?
>>>
>>> Nope.  C2 compiled methods run profile-free.  There can be certain
>>> events that trigger a deopt that will toss out the C2 method (with future
>>> C2 compilations off newly collected profiling possible), but it won?t be
>>> counter based.
>>>
>>>>
>>>>
>>>> I would assume counting stops at that point since we have done all we
>>>> could
>>>> for the method. Also the invocation counting overhead is always
>>>> embarrassing when fighting some C++ guys over claims on how "slow" Java
>>>> is.
>>>> :o)
>>>>
>>>> OTOH, there might be scenarios where it makes sense to have a second
>>>> look
>>>> at "hot" methods, even if they are C2-compiled. Not sure if that
>>>> scenario
>>>> exists in the current infrastructure.
>>>
>>> That infrastructure is called a process restart :) j/k.  There?re some
>>> compiler control APIs, but they?re mostly to allow JIT testing (AFAIK).  I
>>> think it allows manually marking a C2 method for reclaim (ie not entrant),
>>> but I don?t recall the details offhand.
>>>
>>>>
>>>>
>>>> Which one is it in reality?
>>>>
>>>> --
>>>> Stefan Reich
>>>> BotCompany.de // Java-based operating systems
>>>>
>>> --
>>> Sent from my phone
>>>
>>
>>
>> --
>> Stefan Reich
>> BotCompany.de // Java-based operating systems
>>
> --
> Sent from my phone
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From fujie at loongson.cn  Tue Sep 17 01:58:43 2019
From: fujie at loongson.cn (Jie Fu)
Date: Tue, 17 Sep 2019 09:58:43 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
Message-ID: <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>

Hi Ioi and David,

Thank you very much for your review and valuable comments.

Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.02/
 ?-1) Change the error message which is somewhat misleading
 ?-2) Rename "written" to "required_len"

- Before the patch
------------------------------------
[2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
[2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: increase O_BUFLEN in ostream.hpp -- output truncated
...
------------------------------------

- After the patch
------------------------------------
[2019-09-17 09:49:21,567] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: outputStream::do_vsnprintf output truncated -- buffer length is 
2000 bytes but 2013 bytes are needed.
[2019-09-17 09:49:21,571] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: outputStream::do_vsnprintf output truncated -- buffer length is 
2000 bytes but 2031 bytes are needed.
[2019-09-17 09:49:21,576] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
warning: outputStream::do_vsnprintf output truncated -- buffer length is 
2000 bytes but 2049 bytes are needed.
...
------------------------------------

Could you please review it and give me some advice?

Thanks a lot.
Best regards,
Jie

On 2019/9/17 ??7:20, Ioi Lam wrote:
>
>
> On 9/16/19 12:44 AM, David Holmes wrote:
>> On 16/09/2019 5:09 pm, Jie Fu wrote:
>>> Hi David,
>>>
>>> Sorry for the confusion.
>>
>> The confusion is mine, not from you :)
>>
>>> On 2019/9/16 ??2:40, David Holmes wrote:
>>>> Okay I'm confused. I had assumed that the passed in buffer size 
>>>> must be different in each case because of the 2014/2032/2050 values 
>>>> in the message, but in fact they are all sized at 2000. 
>>> According to the source code, the buffer size can be either 
>>> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>>> So it isn't always 2000.
>>
>> It is 2000 is all three examples of the output that you gave.
>
> xmlStream::va_tag() uses 2*K.
>
>>
>>>> That makes no sense
>>> I think it makes sense.
>>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be 
>>> increased if the current buffer size wasn't printed.
>>
>> You need to know the original caller that passed in the buffer size.
>>
>> But we can't just keep increasing the buffer size. We probably need 
>> to examine the callers to see what amount of information is trying to 
>> be passed through. Then decide whether to adjust what the callers are 
>> passing through, or adjust the buffer size - perhaps on a callsite by 
>> callsite basis rather than just bumping O_BUFLEN or BUFLEN.
>>
>
> I think the message should stop saying "increase O_BUFLEN" -- probably 
> the reviewers will reject all future increase of O_BUFLEN and will 
> suggest fixing the caller of outputStream::do_vsnprintf instead.
>
> Callers of outputStream::do_vsnprintf don't necessarily use O_BUFLEN. 
> E.g., xmlStream::va_tag allocates its own buffer. 
> VMError::report_and_die() also uses its own buffer -- it uses O_BUFLEN 
> today, but there's no guarantee or requirement that it always does that.
>
> How about saying something like "outputStream::do_vsnprintf output 
> truncated -- buffer length is 2000 bytes but 2100 bytes are needed."
>
>
>>>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 
>>>> bytes? 
>>>
>>> The output is truncated since the current buffer size is too small 
>>> (e.g., 2000 < 2014).
>>
>> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>>
>> ?102???? int written = os::vsnprintf(buffer, buflen, format, ap);
>>
>> but it isn't "written" when it exceeds buflen, it's the required 
>> buffer size.
>>
>
> I think the variable "written" should be renamed to "required".
>
> Thanks
> - Ioi
>
>> David
>> -----
>>
>>>
>>>> Do we have a bug in os::vsnprintf?
>>>
>>> I don't think so.
>>>
>>> Thanks a lot.
>>> Best regards,
>>> Jie
>>>
>>> [1] 
>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>>
>>> [2] 
>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>>
>>>
>>>
>


From tobias.hartmann at oracle.com  Tue Sep 17 05:20:08 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 17 Sep 2019 07:20:08 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
Message-ID: <dea45bda-6b96-c758-d104-dbeb28d27aeb@oracle.com>

Hi,

I've noticed that -XX:+VerifyOops triggers an unrelated assert failure on Sparc (probably a false
positive similar to JDK-8200288). I've filed JDK-8231100 and disabled the test on Sparc for now.

I've updated the webrev in-place:
http://cr.openjdk.java.net/~thartmann/8231058/webrev.00/

Thanks,
Tobias

On 16.09.19 16:19, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8231058
> http://cr.openjdk.java.net/~thartmann/8231058/webrev.00/
> 
> I've accidentally broke CodeStrings::find_last with my patch for JDK-8224624 [1] but didn't notice
> because the failure only triggers with -XX:+VerifyOops and apparently we don't have any tests that
> execute with that flag.
> 
> The problem is that CodeString::offset() should only be called for comments. I've modified the
> condition accordingly. I've verified that the behavior is now equivalent to before JDK-8224624.
> 
> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8224624
> http://cr.openjdk.java.net/~thartmann/8224624/webrev.00/src/hotspot/share/asm/codeBuffer.cpp.sdiff.html
> 

From david.holmes at oracle.com  Tue Sep 17 05:40:28 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2019 15:40:28 +1000
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
 <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
Message-ID: <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>

Hi Jie,

That seems fine to me.

Thanks,
David
-----

On 17/09/2019 11:58 am, Jie Fu wrote:
> Hi Ioi and David,
> 
> Thank you very much for your review and valuable comments.
> 
> Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.02/
>  ?-1) Change the error message which is somewhat misleading
>  ?-2) Rename "written" to "required_len"
> 
> - Before the patch
> ------------------------------------
> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: increase O_BUFLEN in ostream.hpp -- output truncated
> ...
> ------------------------------------
> 
> - After the patch
> ------------------------------------
> [2019-09-17 09:49:21,567] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: outputStream::do_vsnprintf output truncated -- buffer length is 
> 2000 bytes but 2013 bytes are needed.
> [2019-09-17 09:49:21,571] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: outputStream::do_vsnprintf output truncated -- buffer length is 
> 2000 bytes but 2031 bytes are needed.
> [2019-09-17 09:49:21,576] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
> warning: outputStream::do_vsnprintf output truncated -- buffer length is 
> 2000 bytes but 2049 bytes are needed.
> ...
> ------------------------------------
> 
> Could you please review it and give me some advice?
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> On 2019/9/17 ??7:20, Ioi Lam wrote:
>>
>>
>> On 9/16/19 12:44 AM, David Holmes wrote:
>>> On 16/09/2019 5:09 pm, Jie Fu wrote:
>>>> Hi David,
>>>>
>>>> Sorry for the confusion.
>>>
>>> The confusion is mine, not from you :)
>>>
>>>> On 2019/9/16 ??2:40, David Holmes wrote:
>>>>> Okay I'm confused. I had assumed that the passed in buffer size 
>>>>> must be different in each case because of the 2014/2032/2050 values 
>>>>> in the message, but in fact they are all sized at 2000. 
>>>> According to the source code, the buffer size can be either 
>>>> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>>>> So it isn't always 2000.
>>>
>>> It is 2000 is all three examples of the output that you gave.
>>
>> xmlStream::va_tag() uses 2*K.
>>
>>>
>>>>> That makes no sense
>>>> I think it makes sense.
>>>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be 
>>>> increased if the current buffer size wasn't printed.
>>>
>>> You need to know the original caller that passed in the buffer size.
>>>
>>> But we can't just keep increasing the buffer size. We probably need 
>>> to examine the callers to see what amount of information is trying to 
>>> be passed through. Then decide whether to adjust what the callers are 
>>> passing through, or adjust the buffer size - perhaps on a callsite by 
>>> callsite basis rather than just bumping O_BUFLEN or BUFLEN.
>>>
>>
>> I think the message should stop saying "increase O_BUFLEN" -- probably 
>> the reviewers will reject all future increase of O_BUFLEN and will 
>> suggest fixing the caller of outputStream::do_vsnprintf instead.
>>
>> Callers of outputStream::do_vsnprintf don't necessarily use O_BUFLEN. 
>> E.g., xmlStream::va_tag allocates its own buffer. 
>> VMError::report_and_die() also uses its own buffer -- it uses O_BUFLEN 
>> today, but there's no guarantee or requirement that it always does that.
>>
>> How about saying something like "outputStream::do_vsnprintf output 
>> truncated -- buffer length is 2000 bytes but 2100 bytes are needed."
>>
>>
>>>>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 
>>>>> bytes? 
>>>>
>>>> The output is truncated since the current buffer size is too small 
>>>> (e.g., 2000 < 2014).
>>>
>>> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>>>
>>> ?102???? int written = os::vsnprintf(buffer, buflen, format, ap);
>>>
>>> but it isn't "written" when it exceeds buflen, it's the required 
>>> buffer size.
>>>
>>
>> I think the variable "written" should be renamed to "required".
>>
>> Thanks
>> - Ioi
>>
>>> David
>>> -----
>>>
>>>>
>>>>> Do we have a bug in os::vsnprintf?
>>>>
>>>> I don't think so.
>>>>
>>>> Thanks a lot.
>>>> Best regards,
>>>> Jie
>>>>
>>>> [1] 
>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>>>
>>>> [2] 
>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>>>
>>>>
>>>>
>>
> 

From fujie at loongson.cn  Tue Sep 17 05:45:33 2019
From: fujie at loongson.cn (Jie Fu)
Date: Tue, 17 Sep 2019 13:45:33 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
 <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
 <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
Message-ID: <0da61a5e-ce9e-c49d-9404-8a4fc1c2478d@loongson.cn>

Thanks David.

On 2019/9/17 ??1:40, David Holmes wrote:
> That seems fine to me. 


From ioi.lam at oracle.com  Tue Sep 17 06:21:16 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 16 Sep 2019 23:21:16 -0700
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
 <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
 <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
Message-ID: <7ea059b4-c516-a329-ac56-be2d27a8d3dc@oracle.com>

Hi Jie,

Looks good to me, too. Thanks

- Ioi

On 9/16/19 10:40 PM, David Holmes wrote:
> Hi Jie,
>
> That seems fine to me.
>
> Thanks,
> David
> -----
>
> On 17/09/2019 11:58 am, Jie Fu wrote:
>> Hi Ioi and David,
>>
>> Thank you very much for your review and valuable comments.
>>
>> Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.02/
>> ??-1) Change the error message which is somewhat misleading
>> ??-2) Rename "written" to "required_len"
>>
>> - Before the patch
>> ------------------------------------
>> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>> ...
>> ------------------------------------
>>
>> - After the patch
>> ------------------------------------
>> [2019-09-17 09:49:21,567] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: outputStream::do_vsnprintf output truncated -- buffer length 
>> is 2000 bytes but 2013 bytes are needed.
>> [2019-09-17 09:49:21,571] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: outputStream::do_vsnprintf output truncated -- buffer length 
>> is 2000 bytes but 2031 bytes are needed.
>> [2019-09-17 09:49:21,576] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>> warning: outputStream::do_vsnprintf output truncated -- buffer length 
>> is 2000 bytes but 2049 bytes are needed.
>> ...
>> ------------------------------------
>>
>> Could you please review it and give me some advice?
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>> On 2019/9/17 ??7:20, Ioi Lam wrote:
>>>
>>>
>>> On 9/16/19 12:44 AM, David Holmes wrote:
>>>> On 16/09/2019 5:09 pm, Jie Fu wrote:
>>>>> Hi David,
>>>>>
>>>>> Sorry for the confusion.
>>>>
>>>> The confusion is mine, not from you :)
>>>>
>>>>> On 2019/9/16 ??2:40, David Holmes wrote:
>>>>>> Okay I'm confused. I had assumed that the passed in buffer size 
>>>>>> must be different in each case because of the 2014/2032/2050 
>>>>>> values in the message, but in fact they are all sized at 2000. 
>>>>> According to the source code, the buffer size can be either 
>>>>> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>>>>> So it isn't always 2000.
>>>>
>>>> It is 2000 is all three examples of the output that you gave.
>>>
>>> xmlStream::va_tag() uses 2*K.
>>>
>>>>
>>>>>> That makes no sense
>>>>> I think it makes sense.
>>>>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be 
>>>>> increased if the current buffer size wasn't printed.
>>>>
>>>> You need to know the original caller that passed in the buffer size.
>>>>
>>>> But we can't just keep increasing the buffer size. We probably need 
>>>> to examine the callers to see what amount of information is trying 
>>>> to be passed through. Then decide whether to adjust what the 
>>>> callers are passing through, or adjust the buffer size - perhaps on 
>>>> a callsite by callsite basis rather than just bumping O_BUFLEN or 
>>>> BUFLEN.
>>>>
>>>
>>> I think the message should stop saying "increase O_BUFLEN" -- 
>>> probably the reviewers will reject all future increase of O_BUFLEN 
>>> and will suggest fixing the caller of outputStream::do_vsnprintf 
>>> instead.
>>>
>>> Callers of outputStream::do_vsnprintf don't necessarily use 
>>> O_BUFLEN. E.g., xmlStream::va_tag allocates its own buffer. 
>>> VMError::report_and_die() also uses its own buffer -- it uses 
>>> O_BUFLEN today, but there's no guarantee or requirement that it 
>>> always does that.
>>>
>>> How about saying something like "outputStream::do_vsnprintf output 
>>> truncated -- buffer length is 2000 bytes but 2100 bytes are needed."
>>>
>>>
>>>>>> - how can we have written e.g. 2014 bytes to a buffer of only 
>>>>>> 2000 bytes? 
>>>>>
>>>>> The output is truncated since the current buffer size is too small 
>>>>> (e.g., 2000 < 2014).
>>>>
>>>> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>>>>
>>>> ?102???? int written = os::vsnprintf(buffer, buflen, format, ap);
>>>>
>>>> but it isn't "written" when it exceeds buflen, it's the required 
>>>> buffer size.
>>>>
>>>
>>> I think the variable "written" should be renamed to "required".
>>>
>>> Thanks
>>> - Ioi
>>>
>>>> David
>>>> -----
>>>>
>>>>>
>>>>>> Do we have a bug in os::vsnprintf?
>>>>>
>>>>> I don't think so.
>>>>>
>>>>> Thanks a lot.
>>>>> Best regards,
>>>>> Jie
>>>>>
>>>>> [1] 
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>>>>
>>>>> [2] 
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>>>>
>>>>>
>>>>>
>>>
>>


From fujie at loongson.cn  Tue Sep 17 06:28:13 2019
From: fujie at loongson.cn (Jie Fu)
Date: Tue, 17 Sep 2019 14:28:13 +0800
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <7ea059b4-c516-a329-ac56-be2d27a8d3dc@oracle.com>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
 <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
 <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
 <7ea059b4-c516-a329-ac56-be2d27a8d3dc@oracle.com>
Message-ID: <b2de9f01-8e18-e97b-8dd6-e323fa102a2a@loongson.cn>

Hi Ioi,

Thank you so much.

I would be appreciated if you could sponsor it.

Thanks a lot.
Best regards,
Jie

On 2019/9/17 ??2:21, Ioi Lam wrote:
> Hi Jie,
>
> Looks good to me, too. Thanks
>
> - Ioi
>
> On 9/16/19 10:40 PM, David Holmes wrote:
>> Hi Jie,
>>
>> That seems fine to me.
>>
>> Thanks,
>> David
>> -----
>>
>> On 17/09/2019 11:58 am, Jie Fu wrote:
>>> Hi Ioi and David,
>>>
>>> Thank you very much for your review and valuable comments.
>>>
>>> Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.02/
>>> ??-1) Change the error message which is somewhat misleading
>>> ??-2) Rename "written" to "required_len"
>>>
>>> - Before the patch
>>> ------------------------------------
>>> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>> ...
>>> ------------------------------------
>>>
>>> - After the patch
>>> ------------------------------------
>>> [2019-09-17 09:49:21,567] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: outputStream::do_vsnprintf output truncated -- buffer 
>>> length is 2000 bytes but 2013 bytes are needed.
>>> [2019-09-17 09:49:21,571] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: outputStream::do_vsnprintf output truncated -- buffer 
>>> length is 2000 bytes but 2031 bytes are needed.
>>> [2019-09-17 09:49:21,576] Agent[1]: stderr: OpenJDK 64-Bit Server VM 
>>> warning: outputStream::do_vsnprintf output truncated -- buffer 
>>> length is 2000 bytes but 2049 bytes are needed.
>>> ...
>>> ------------------------------------
>>>
>>> Could you please review it and give me some advice?
>>>
>>> Thanks a lot.
>>> Best regards,
>>> Jie
>>>
>>> On 2019/9/17 ??7:20, Ioi Lam wrote:
>>>>
>>>>
>>>> On 9/16/19 12:44 AM, David Holmes wrote:
>>>>> On 16/09/2019 5:09 pm, Jie Fu wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> Sorry for the confusion.
>>>>>
>>>>> The confusion is mine, not from you :)
>>>>>
>>>>>> On 2019/9/16 ??2:40, David Holmes wrote:
>>>>>>> Okay I'm confused. I had assumed that the passed in buffer size 
>>>>>>> must be different in each case because of the 2014/2032/2050 
>>>>>>> values in the message, but in fact they are all sized at 2000. 
>>>>>> According to the source code, the buffer size can be either 
>>>>>> 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>>>>>> So it isn't always 2000.
>>>>>
>>>>> It is 2000 is all three examples of the output that you gave.
>>>>
>>>> xmlStream::va_tag() uses 2*K.
>>>>
>>>>>
>>>>>>> That makes no sense
>>>>>> I think it makes sense.
>>>>>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be 
>>>>>> increased if the current buffer size wasn't printed.
>>>>>
>>>>> You need to know the original caller that passed in the buffer size.
>>>>>
>>>>> But we can't just keep increasing the buffer size. We probably 
>>>>> need to examine the callers to see what amount of information is 
>>>>> trying to be passed through. Then decide whether to adjust what 
>>>>> the callers are passing through, or adjust the buffer size - 
>>>>> perhaps on a callsite by callsite basis rather than just bumping 
>>>>> O_BUFLEN or BUFLEN.
>>>>>
>>>>
>>>> I think the message should stop saying "increase O_BUFLEN" -- 
>>>> probably the reviewers will reject all future increase of O_BUFLEN 
>>>> and will suggest fixing the caller of outputStream::do_vsnprintf 
>>>> instead.
>>>>
>>>> Callers of outputStream::do_vsnprintf don't necessarily use 
>>>> O_BUFLEN. E.g., xmlStream::va_tag allocates its own buffer. 
>>>> VMError::report_and_die() also uses its own buffer -- it uses 
>>>> O_BUFLEN today, but there's no guarantee or requirement that it 
>>>> always does that.
>>>>
>>>> How about saying something like "outputStream::do_vsnprintf output 
>>>> truncated -- buffer length is 2000 bytes but 2100 bytes are needed."
>>>>
>>>>
>>>>>>> - how can we have written e.g. 2014 bytes to a buffer of only 
>>>>>>> 2000 bytes? 
>>>>>>
>>>>>> The output is truncated since the current buffer size is too 
>>>>>> small (e.g., 2000 < 2014).
>>>>>
>>>>> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>>>>>
>>>>> ?102???? int written = os::vsnprintf(buffer, buflen, format, ap);
>>>>>
>>>>> but it isn't "written" when it exceeds buflen, it's the required 
>>>>> buffer size.
>>>>>
>>>>
>>>> I think the variable "written" should be renamed to "required".
>>>>
>>>> Thanks
>>>> - Ioi
>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>>> Do we have a bug in os::vsnprintf?
>>>>>>
>>>>>> I don't think so.
>>>>>>
>>>>>> Thanks a lot.
>>>>>> Best regards,
>>>>>> Jie
>>>>>>
>>>>>> [1] 
>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>>>>>
>>>>>> [2] 
>>>>>> http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>


From IOI.LAM at ORACLE.COM  Tue Sep 17 07:00:29 2019
From: IOI.LAM at ORACLE.COM (Ioi Lam)
Date: Tue, 17 Sep 2019 00:00:29 -0700
Subject: RFR(trivial): 8231024: Improve the debug info when the output is
 truncated
In-Reply-To: <b2de9f01-8e18-e97b-8dd6-e323fa102a2a@loongson.cn>
References: <edf07786-cbe8-d6ad-3c15-50ab8e5177db@loongson.cn>
 <bbdd3658-92ad-b5bc-92d3-42c07de1f07e@oracle.com>
 <211e8d53-4150-b9eb-3955-4a64d31c9a3d@loongson.cn>
 <a018631a-7bdc-d99a-0739-8785cc9a8760@loongson.cn>
 <f79ced42-e3c1-7486-9e7c-142c421e844c@oracle.com>
 <da619b22-c8b8-acc2-1f5e-7558290834b4@loongson.cn>
 <9e689f03-eda0-f954-56e1-e06e2b83836a@oracle.com>
 <1ae1f7ee-0e3b-f65a-a2a3-3a8ea1609a7a@oracle.com>
 <6cc7b4cb-378f-b8d5-8953-896604c643e3@loongson.cn>
 <fffdce0c-bdd6-a185-b9df-3b11b3f4ad16@oracle.com>
 <7ea059b4-c516-a329-ac56-be2d27a8d3dc@oracle.com>
 <b2de9f01-8e18-e97b-8dd6-e323fa102a2a@loongson.cn>
Message-ID: <97A7475F-B6DF-485D-80C3-A2AFD1696E0D@ORACLE.COM>

Sure I?ll test and push that tomorrow.

Thanks
Ioi

> On Sep 16, 2019, at 11:28 PM, Jie Fu <fujie at loongson.cn> wrote:
> 
> Hi Ioi,
> 
> Thank you so much.
> 
> I would be appreciated if you could sponsor it.
> 
> Thanks a lot.
> Best regards,
> Jie
> 
>> On 2019/9/17 ??2:21, Ioi Lam wrote:
>> Hi Jie,
>> 
>> Looks good to me, too. Thanks
>> 
>> - Ioi
>> 
>>> On 9/16/19 10:40 PM, David Holmes wrote:
>>> Hi Jie,
>>> 
>>> That seems fine to me.
>>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> On 17/09/2019 11:58 am, Jie Fu wrote:
>>>> Hi Ioi and David,
>>>> 
>>>> Thank you very much for your review and valuable comments.
>>>> 
>>>> Updated: http://cr.openjdk.java.net/~jiefu/8231024/webrev.02/
>>>>   -1) Change the error message which is somewhat misleading
>>>>   -2) Rename "written" to "required_len"
>>>> 
>>>> - Before the patch
>>>> ------------------------------------
>>>> [2019-09-14 16:07:55,752] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>>> [2019-09-14 16:07:55,758] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>>> [2019-09-14 16:07:55,763] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated
>>>> ...
>>>> ------------------------------------
>>>> 
>>>> - After the patch
>>>> ------------------------------------
>>>> [2019-09-17 09:49:21,567] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 2013 bytes are needed.
>>>> [2019-09-17 09:49:21,571] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 2031 bytes are needed.
>>>> [2019-09-17 09:49:21,576] Agent[1]: stderr: OpenJDK 64-Bit Server VM warning: outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 2049 bytes are needed.
>>>> ...
>>>> ------------------------------------
>>>> 
>>>> Could you please review it and give me some advice?
>>>> 
>>>> Thanks a lot.
>>>> Best regards,
>>>> Jie
>>>> 
>>>>> On 2019/9/17 ??7:20, Ioi Lam wrote:
>>>>> 
>>>>> 
>>>>>> On 9/16/19 12:44 AM, David Holmes wrote:
>>>>>>> On 16/09/2019 5:09 pm, Jie Fu wrote:
>>>>>>> Hi David,
>>>>>>> 
>>>>>>> Sorry for the confusion.
>>>>>> 
>>>>>> The confusion is mine, not from you :)
>>>>>> 
>>>>>>>> On 2019/9/16 ??2:40, David Holmes wrote:
>>>>>>>> Okay I'm confused. I had assumed that the passed in buffer size must be different in each case because of the 2014/2032/2050 values in the message, but in fact they are all sized at 2000. 
>>>>>>> According to the source code, the buffer size can be either 2000(O_BUFLEN) [1] or 2048(BUFLEN) [2].
>>>>>>> So it isn't always 2000.
>>>>>> 
>>>>>> It is 2000 is all three examples of the output that you gave.
>>>>> 
>>>>> xmlStream::va_tag() uses 2*K.
>>>>> 
>>>>>> 
>>>>>>>> That makes no sense
>>>>>>> I think it makes sense.
>>>>>>> It is still unclear which one (O_BUFLEN or BUFLEN?) should be increased if the current buffer size wasn't printed.
>>>>>> 
>>>>>> You need to know the original caller that passed in the buffer size.
>>>>>> 
>>>>>> But we can't just keep increasing the buffer size. We probably need to examine the callers to see what amount of information is trying to be passed through. Then decide whether to adjust what the callers are passing through, or adjust the buffer size - perhaps on a callsite by callsite basis rather than just bumping O_BUFLEN or BUFLEN.
>>>>>> 
>>>>> 
>>>>> I think the message should stop saying "increase O_BUFLEN" -- probably the reviewers will reject all future increase of O_BUFLEN and will suggest fixing the caller of outputStream::do_vsnprintf instead.
>>>>> 
>>>>> Callers of outputStream::do_vsnprintf don't necessarily use O_BUFLEN. E.g., xmlStream::va_tag allocates its own buffer. VMError::report_and_die() also uses its own buffer -- it uses O_BUFLEN today, but there's no guarantee or requirement that it always does that.
>>>>> 
>>>>> How about saying something like "outputStream::do_vsnprintf output truncated -- buffer length is 2000 bytes but 2100 bytes are needed."
>>>>> 
>>>>> 
>>>>>>>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 bytes? 
>>>>>>> 
>>>>>>> The output is truncated since the current buffer size is too small (e.g., 2000 < 2014).
>>>>>> 
>>>>>> Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
>>>>>> 
>>>>>>  102     int written = os::vsnprintf(buffer, buflen, format, ap);
>>>>>> 
>>>>>> but it isn't "written" when it exceeds buflen, it's the required buffer size.
>>>>>> 
>>>>> 
>>>>> I think the variable "written" should be renamed to "required".
>>>>> 
>>>>> Thanks
>>>>> - Ioi
>>>>> 
>>>>>> David
>>>>>> -----
>>>>>> 
>>>>>>> 
>>>>>>>> Do we have a bug in os::vsnprintf?
>>>>>>> 
>>>>>>> I don't think so.
>>>>>>> 
>>>>>>> Thanks a lot.
>>>>>>> Best regards,
>>>>>>> Jie
>>>>>>> 
>>>>>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/ostream.cpp#l124 
>>>>>>> [2] http://hg.openjdk.java.net/jdk/jdk/file/24df796eef3d/src/hotspot/share/utilities/xmlstream.cpp#l138 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>> 
> 


From christoph.langer at sap.com  Tue Sep 17 08:50:22 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 17 Sep 2019 08:50:22 +0000
Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer
 types and string literal conversion warnings
In-Reply-To: <AM6PR02MB5078A4042DB34CCFB1B88A7293C10@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078A1B995359982495CFB1C93C70@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <AM6PR02MB47888FB2BE46EEF137AED2229AC60@AM6PR02MB4788.eurprd02.prod.outlook.com>
 <AM6PR02MB5078A4042DB34CCFB1B88A7293C10@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB519285A7980C7577675842738A8F0@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Matthias,

this seems fine to me. The change in NetworkInterface.c is correct, too.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Baesken, Matthias
> Sent: Donnerstag, 25. Juli 2019 15:45
> To: Doerr, Martin <martin.doerr at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net; net-dev at openjdk.java.net
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net>
> Subject: [CAUTION] RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct
> pointer types and string literal conversion warnings
> 
> Thanks Martin .
> May I get a second review ?
> 
> Best regards, Matthias
> 
> 
> From: Doerr, Martin
> Sent: Mittwoch, 24. Juli 2019 12:14
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net; net-dev at openjdk.java.net
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net>
> Subject: RE: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer
> types and string literal conversion warnings
> 
> Hi Matthias,
> 
> I wouldn?t say ?looks good?, but I think it?s the right thing to do ??
> The type casts look correct to fit to the AIX headers.
> 
> libodm_aix:
> Good. Maybe we should open a new issue for freeing what?s returned by
> odm_set_path and we could also remove the AIX 5 support.
> 
> NetworkInterface.c:
> Strange, but ok. Should be reviewed by somebody else in addition.
> 
> Other files:
> No comments.
> 
> Best regards,
> Martin
> 
> 
> From: ppc-aix-port-dev <ppc-aix-port-dev-
> bounces at openjdk.java.net<mailto:ppc-aix-port-dev-
> bounces at openjdk.java.net>> On Behalf Of Baesken, Matthias
> Sent: Dienstag, 23. Juli 2019 17:15
> To: 'hotspot-dev at openjdk.java.net' <hotspot-
> dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>>; core-libs-
> dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; net-
> dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>
> Cc: 'ppc-aix-port-dev at openjdk.java.net' <ppc-aix-port-
> dev at openjdk.java.net<mailto:ppc-aix-port-dev at openjdk.java.net>>
> Subject: RFR: 8228482: fix xlc16/xlclang comparison of distinct pointer types
> and string literal conversion warnings
> 
> Hello please review this patch .
> 
> It fixes a couple of  xlc16/xlclang warnings  , especially  comparison of distinct
> pointer types and string literal conversion warnings  .
> 
> When building with xlc16/xlclang, we still have a couple of warnings that have
> to be fixed :
> warning: ISO C++11 does not allow conversion from string literal to 'char *' [-
> Wwritable-strings]
> for example :
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:18: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
>                  ^
> /nightly/jdk/src/hotspot/os/aix/libodm_aix.cpp:81:29: warning: ISO C++11
> does not allow conversion from string literal to 'char *' [-Wwritable-strings]
>   odmWrapper odm("product", "/usr/lib/objrepos"); // could also use "lpp"
>                             ^
> 
> warning: comparison of distinct pointer types, for example :
> 
> /nightly/jdk/src/java.desktop/aix/native/libawt/porting_aix.c:50:14:
> warning: comparison of distinct pointer types ('void *' and 'char *') [-
> Wcompare-distinct-pointer-types]
>         addr < (((char*)p->ldinfo_textorg) + p->ldinfo_textsize)) {
>         ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> 
> Bug/webrev :
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8228482
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8228482.1/
> 
> 
> Thanks, Matthias
> 


From robbin.ehn at oracle.com  Tue Sep 17 12:05:12 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 17 Sep 2019 14:05:12 +0200
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
In-Reply-To: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
References: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
Message-ID: <f44fc156-d5a8-6303-1ef3-e144c9588427@oracle.com>

Hi David,

Nit, double indent on if-statement here:
src/hotspot/share/runtime/thread.cpp
+void JavaThread::interrupt() {
+  debug_only(check_for_dangling_thread_pointer(this);)
+
+    if (!osthread()->interrupted()) {

> If you are wondering why Windows used OrderAccess::release while POSIX used OrderAccess::fence, I have no idea, and I do 
> not intend to change either of them. The only safe change would be to use fence() in both cases, which just makes the 
> Windows wart worse - and unnecessarily so as we have seen no bugs using the existing release().

unpark() do Atomic::xchg, so fence is not needed.
SetEvent is a syscall, so release is not needed.
No need to change, you can leave them as is.

Looks good, thanks! (no need for an update)

/Robbin


> 
> Testing:
>  ?- hotspot runtime
>  ?- Tiers 1-3
> 
> Thanks,
> David

From robbin.ehn at oracle.com  Tue Sep 17 12:05:42 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 17 Sep 2019 14:05:42 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
 <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>
Message-ID: <e316ccd7-b5e7-3c7f-836f-71727cbecc98@oracle.com>

Thanks Patricio!

/Robbin

On 2019-09-16 17:29, Patricio Chilano wrote:
> Hi Robbin,
> 
> Changes look good to me. Thanks for the fixes!
> 
> Patricio
> On 9/12/19 8:21 AM, Robbin Ehn wrote:
>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>
>> Passed t1-5, doing some more testing also.
>>
>> Thanks, Robbin
>>
>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>> Hi, hotspot-dev was the intended list.
>>>
>>> Thanks, Robbin
>>>
>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>> Hi all, please consider,
>>>>
>>>> To get away from the issues of us revoking in the handshake, but before deopt
>>>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>>>> handler.
>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>>
>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>>>> some pieces did not apply:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>> So this is what was reviewed.
>>>>
>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>
>>>> Bug 8224795 fix is here:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html
>>>>
>>>> After this we have the same functionally as the reverted change-set.
>>>>
>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>
>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>> Here is a refactoring of that code. (also removed a dead method in biasedlocking):
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>
>>>> And here is full:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>
>>>> Also a full squashed patch file:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>
>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>> running.
>>>>
>>>> Thanks, Robbin
>>>>
>>>>
> 

From robbin.ehn at oracle.com  Tue Sep 17 12:05:54 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 17 Sep 2019 14:05:54 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <853c17a2-beec-46b4-2fa3-5f8dd321aba5@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
 <c8ab9541-7290-30d9-3564-858e43a2d95b@oracle.com>
 <853c17a2-beec-46b4-2fa3-5f8dd321aba5@oracle.com>
Message-ID: <bd69b767-6017-a482-f64a-977350b5c33e@oracle.com>

Thanks Dan!

/Robbin

On 2019-09-16 18:43, Daniel D. Daugherty wrote:
> Looks good to me also.
> 
> Dan
> 
> 
> On 9/16/19 11:29 AM, Patricio Chilano wrote:
>> Hi Robbin,
>>
>> Changes look good to me. Thanks for the fixes!
>>
>> Patricio
>> On 9/12/19 8:21 AM, Robbin Ehn wrote:
>>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>>
>>> Inc:
>>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>>
>>> Passed t1-5, doing some more testing also.
>>>
>>> Thanks, Robbin
>>>
>>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>>> Hi, hotspot-dev was the intended list.
>>>>
>>>> Thanks, Robbin
>>>>
>>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>>> Hi all, please consider,
>>>>>
>>>>> To get away from the issues of us revoking in the handshake, but before deopt
>>>>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>>>>> handler.
>>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>>>
>>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>>>>> some pieces did not apply:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>>> So this is what was reviewed.
>>>>>
>>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>>
>>>>> Bug 8224795 fix is here:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html
>>>>>
>>>>> After this we have the same functionally as the reverted change-set.
>>>>>
>>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>>
>>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>>> Here is a refactoring of that code. (also removed a dead method in biasedlocking):
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>>
>>>>> And here is full:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>>
>>>>> Also a full squashed patch file:
>>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>>
>>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>>> running.
>>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>>
>>
> 

From erik.joelsson at oracle.com  Tue Sep 17 13:16:24 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 17 Sep 2019 06:16:24 -0700
Subject: [14] Review Request: JDK-8231027 Correct typos
In-Reply-To: <bef4fd4f-7eb6-4502-710a-d04d6ed9d810@oracle.com>
References: <bef4fd4f-7eb6-4502-710a-d04d6ed9d810@oracle.com>
Message-ID: <17674991-934e-7053-d59e-35f6e1569d9c@oracle.com>

Looks good.

/Erik

On 2019-09-16 14:50, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 14.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8231027
> Fix: http://cr.openjdk.java.net/~serb/8231027/webrev.00
>
> One common typo is fixed across a few components like client, build, 
> and hotspot.
>

From david.holmes at oracle.com  Tue Sep 17 13:27:20 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Sep 2019 23:27:20 +1000
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
In-Reply-To: <f44fc156-d5a8-6303-1ef3-e144c9588427@oracle.com>
References: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
 <f44fc156-d5a8-6303-1ef3-e144c9588427@oracle.com>
Message-ID: <be28f074-1989-2f32-81fa-0498c4fd1605@oracle.com>

Hi Robbin,

Thanks for taking a look at this.

On 17/09/2019 10:05 pm, Robbin Ehn wrote:
> Hi David,
> 
> Nit, double indent on if-statement here:
> src/hotspot/share/runtime/thread.cpp
> +void JavaThread::interrupt() {
> +? debug_only(check_for_dangling_thread_pointer(this);)
> +
> +??? if (!osthread()->interrupted()) {

Fixed. emacs doesn't like those debug_only() constructs and keeps 
"fixing" the indent on the next line. :)

>> If you are wondering why Windows used OrderAccess::release while POSIX 
>> used OrderAccess::fence, I have no idea, and I do not intend to change 
>> either of them. The only safe change would be to use fence() in both 
>> cases, which just makes the Windows wart worse - and unnecessarily so 
>> as we have seen no bugs using the existing release().
> 
> unpark() do Atomic::xchg, so fence is not needed.
> SetEvent is a syscall, so release is not needed.
> No need to change, you can leave them as is.

I was assuming the key thing was to "flush" the write to the interrupted 
state ASAP to minimise the chance of a race resulting in multiple calls 
to SetEvent/unpark. But it seems to have just been copied through 
history. This dates back to the early Solaris code, where interrupts 
also involved signals, and release semantics were used to write the 
interrupted state. That morphed into an atomic::membar which later 
evolved into OrderAccess::fence(). At the same time OrderAccess was 
introduced the Windows code was updated to "use release like Solaris" - 
even though Solaris was already using a fence(). Linux inherited the 
fence from Solaris; BSD/AIX inherited the fence from Linux and 
eventually it ended up as the POSIX form.

> Looks good, thanks! (no need for an update)

Thanks for the review!

David
-----

> /Robbin
> 
> 
>>
>> Testing:
>> ??- hotspot runtime
>> ??- Tiers 1-3
>>
>> Thanks,
>> David

From daniel.daugherty at oracle.com  Tue Sep 17 14:13:03 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 17 Sep 2019 10:13:03 -0400
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
In-Reply-To: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
References: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
Message-ID: <e4aa15bc-5154-4ef4-f83e-6e20c03e0294@oracle.com>

On 9/13/19 5:12 AM, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8230424/webrev/

src/hotspot/os/posix/os_posix.cpp
 ??? The old _sleepEvent code had a check for a NULL _SleepEvent
 ??? before unparking.
 ??? The old _ParkEvent code had a check for a NULL _ParkEvent
 ??? before unparking.

 ??? Update: The code review invite covered this:

 ????? > - minor cleanups to the logic of interrupt() as we can never
 ????? >?? have NULL events as we are always guaranteed to be operating
 ????? >?? on a live thread.

src/hotspot/os/solaris/os_solaris.cpp
 ??? No comments.

src/hotspot/os/windows/osThread_windows.cpp
 ??? No comments.

src/hotspot/os/windows/osThread_windows.hpp
 ??? No comments.

src/hotspot/os/windows/os_windows.cpp
 ??? Where did the JSR166 support move to?
 ??? Update: moved to thread.cpp so okay.

src/hotspot/share/jvmci/jvmciRuntime.cpp
 ??? No comments.

src/hotspot/share/prims/jvm.cpp
 ??? No comments.

src/hotspot/share/prims/jvmtiEnv.cpp
 ??? No comments.

src/hotspot/share/prims/jvmtiRawMonitor.cpp
 ??? No comments.

src/hotspot/share/runtime/objectMonitor.cpp
 ??? No comments (the Self -> jt changes threw me for a second :-)).

src/hotspot/share/runtime/os.hpp
 ??? No comments.

src/hotspot/share/runtime/osThread.cpp
 ??? No comments.

src/hotspot/share/runtime/osThread.hpp
 ??? No comments.

src/hotspot/share/runtime/thread.cpp
 ??? No comments.

src/hotspot/share/runtime/thread.hpp
 ??? No comments.


Thumbs up! Robbin flagged the one nit indent issue that I spotted.
I don't need to see another webrev.

Dan


> bug: https://bugs.openjdk.java.net/browse/JDK-8230424
>
> The next instalment of the interruption logic refactoring.
>
> Summary of changes:
> - the windows-specific actions in os:interrupt and os::is_interrupted 
> are pushed down into the windows-specific osThread code. This all 
> relates to the only-used-by-the-JDK _interrupt_event.
> - the POSIX variant of os::interrupt and os::is_interrupted is inlined 
> as platform-independent code in the Thread versions and those versions 
> are themselves moved to JavaThread as instance methods.
> - minor cleanups to the logic of interrupt() as we can never have NULL 
> events as we are always guaranteed to be operating on a live thread.
> - All call sites adjusted as needed.
>
> One minor wart in this refactor is that on Windows we will execute an 
> OrderAccess::release() after setting the interrupt state in the 
> platform code, and then execute an additional fence() in the shared 
> code. I don't think this is worth trying to "fix" - and hopefully if 
> we can get rid of the Windows _interrupt_event this will all go away.
>
> If you are wondering why Windows used OrderAccess::release while POSIX 
> used OrderAccess::fence, I have no idea, and I do not intend to change 
> either of them. The only safe change would be to use fence() in both 
> cases, which just makes the Windows wart worse - and unnecessarily so 
> as we have seen no bugs using the existing release().
>
> Testing:
> ?- hotspot runtime
> ?- Tiers 1-3
>
> Thanks,
> David


From matthias.baesken at sap.com  Tue Sep 17 14:18:26 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 17 Sep 2019 14:18:26 +0000
Subject: sun.java.launcher.pid  property usage
Message-ID: <AM6PR02MB5078E1670EDB0D342393363E938F0@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello,  while looking at some  atoi usages in the codebase I started to wonder about the  "sun.java.launcher.pid"  property.
Currently in java_md_solinux.c  the property is set on Linux only  by default (code is guarded #ifdef __linux__ ).
Later it is passed  to the int  variable _sun_java_launcher_pid (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.

Is the property still supported (one would need to set it from user side on the command line on non-Linux because it is not set by default on bsd/macOS) ?
Can the coding be removed (or should it enabled for BSD/Mac like we do on Linux) ?

The os_bsd comment mentiones the bug 6351349 :

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
JDK-6351349 : On linux with the old thread lib, jps should return the same PID as $!

but this looks very old.

Best regards, Matthias




coding parts mentioned :

src/hotspot/os/bsd/os_bsd.cpp
-----------------------------------

void os::init(void) {
  char dummy;   // used to get a guess on initial stack address

  // With BsdThreads the JavaMain thread pid (primordial thread)
  // is different than the pid of the java launcher thread.
  // So, on Bsd, the launcher thread pid is passed to the VM
  // via the sun.java.launcher.pid property.
  // Use this property instead of getpid() if it was correctly passed.
  // See bug 6351349.
  pid_t java_launcher_pid = (pid_t) Arguments::sun_java_launcher_pid();

  _initial_pid = (java_launcher_pid > 0) ? java_launcher_pid : getpid();


arguments.cpp / hpp
---------------------

    if (match_option(option, "-Dsun.java.launcher.pid=", &tail)) {
      _sun_java_launcher_pid = atoi(tail);
      continue;
    }

  static int sun_java_launcher_pid()        { return _sun_java_launcher_pid; }


java_md_solinux.c
---------------------

void SetJavaLauncherPlatformProps() {
   /* Linux only */
#ifdef __linux__
    const char *substr = "-Dsun.java.launcher.pid=";
    char *pid_prop_str = (char *)JLI_MemAlloc(JLI_StrLen(substr) + MAX_PID_STR_SZ + 1);
    sprintf(pid_prop_str, "%s%d", substr, getpid());
    AddOption(pid_prop_str, NULL);
#endif /* __linux__ */
}


From erik.osterlund at oracle.com  Tue Sep 17 14:24:48 2019
From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=)
Date: Tue, 17 Sep 2019 16:24:48 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
Message-ID: <9d1c1a88-a8be-a05a-6c1a-e6161556e4bb@oracle.com>

Hi Robbin,

Excellent. This looks good.

Thanks,
/Erik

On 2019-09-12 13:21, Robbin Ehn wrote:
> Hi, here is v3, addressing Patricio's and Dan's review comments.
>
> Inc:
> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>
> Passed t1-5, doing some more testing also.
>
> Thanks, Robbin
>
> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>> Hi, hotspot-dev was the intended list.
>>
>> Thanks, Robbin
>>
>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>> Hi all, please consider,
>>>
>>> To get away from the issues of us revoking in the handshake, but 
>>> before deopt
>>> the locks get re-biased before we hit deopt handler, we instead 
>>> revoke in deopt
>>> handler.
>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we 
>>> revoke after
>>> that but before we start looking at the monitors, with a 
>>> NoSafepointVerifier.
>>>
>>> Here is the previous changeset on top of jdk/jdk tip but due to 
>>> merge conflicts
>>> some pieces did not apply:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ 
>>>
>>> So this is what was reviewed.
>>>
>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>
>>> Bug 8224795 fix is here:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>
>>>
>>> After this we have the same functionally as the reverted change-set.
>>>
>>> Here is the changes for doing the revoke in deopt handler instead:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ 
>>>
>>>
>>> This code was messy adding the deopt revocation in 3 places made it 
>>> worse.
>>> Here is a refactoring of that code. (also removed a dead method in 
>>> biasedlocking):
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>
>>> And here is full:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>
>>> Also a full squashed patch file:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>
>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX 
>>> still
>>> running.
>>>
>>> Thanks, Robbin
>>>
>>>


From robbin.ehn at oracle.com  Tue Sep 17 14:39:02 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 17 Sep 2019 16:39:02 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <9d1c1a88-a8be-a05a-6c1a-e6161556e4bb@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
 <9d1c1a88-a8be-a05a-6c1a-e6161556e4bb@oracle.com>
Message-ID: <cb462833-fbd3-fa54-ff87-88e86a07af43@oracle.com>

Thanks Erik!

/Robbin

On 2019-09-17 16:24, Erik ?sterlund wrote:
> Hi Robbin,
> 
> Excellent. This looks good.
> 
> Thanks,
> /Erik
> 
> On 2019-09-12 13:21, Robbin Ehn wrote:
>> Hi, here is v3, addressing Patricio's and Dan's review comments.
>>
>> Inc:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
>>
>> Full:
>> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
>>
>> Passed t1-5, doing some more testing also.
>>
>> Thanks, Robbin
>>
>> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>>> Hi, hotspot-dev was the intended list.
>>>
>>> Thanks, Robbin
>>>
>>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>>> Hi all, please consider,
>>>>
>>>> To get away from the issues of us revoking in the handshake, but before deopt
>>>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>>>> handler.
>>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>>
>>>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>>>> some pieces did not apply:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>>> So this is what was reviewed.
>>>>
>>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>>
>>>> Bug 8224795 fix is here:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html
>>>>
>>>> After this we have the same functionally as the reverted change-set.
>>>>
>>>> Here is the changes for doing the revoke in deopt handler instead:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>>
>>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>>> Here is a refactoring of that code. (also removed a dead method in biasedlocking):
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>>
>>>> And here is full:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>>
>>>> Also a full squashed patch file:
>>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>>
>>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>>> running.
>>>>
>>>> Thanks, Robbin
>>>>
>>>>
> 

From joe.darcy at oracle.com  Tue Sep 17 20:00:43 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 17 Sep 2019 13:00:43 -0700
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
 <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>
 <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <5d947cc5-171c-18fb-a33f-0bed7eeeb970@oracle.com>

Hello,

The specification for the SuppressWarnings type states:

"The presence of unrecognized warning names is /not/ an error: Compilers 
must ignore any warning names they do not recognize. They are, however, 
free to emit a warning if an annotation contains an unrecognized warning 
name."
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/SuppressWarnings.html#value()

Note that the JLS does not repeat this requirement of compilers in its 
section on @SuppressWarnings:

https://docs.oracle.com/javase/specs/jls/se13/html/jls-9.html#jls-9.6.4.5

I've filed JDK-8231147 for this issue.

HTH,

-Joe

On 9/13/2019 1:04 AM, Langer, Christoph wrote:
> Hi David,
>
>>>> test/lib/jdk/test/lib/process/ProcessTools.java
>>>>
>>>> -     @SuppressWarnings("overloads")
>>>>          public static Process startProcess(String name,
>>>>                                             ProcessBuilder processBuilder,
>>>>                                             final Predicate<String>
>>>> linePredicate)
>>>>
>>>> Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?
>>> I didn't find any reference either and the IDE says that this is an unknown
>> annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.
>>
>> Not it is a valid warning. Try compiling with -Xlint:all without the
>> warning suppressed:
>>
>> ----------System.err:(19/1295)----------
>> /scratch/users/daholme/jdk-
>> dev2/open/test/lib/jdk/test/lib/process/ProcessTools.java:91:
>> warning: [overloads]
>> startProcess(String,ProcessBuilder,Consumer<String>) in ProcessTools is
>> potentially ambiguous with
>> startProcess(String,ProcessBuilder,Predicate<String>) in ProcessTools
>>       public static Process startProcess(String name,
>>                             ^
> Thanks for taking a closer look here and enlightening me.
>
> @SuppressWarnings("overloads") is supported by javac but not by my Eclipse IDE. One can list supported @SuppressWarnings types with javac -X. You'll get:
> overloads            Warn about issues regarding method overloads.
>
> So I now understand what the warning means and why @SuppressWarnings("overloads") is required here. I've also configured my Eclipse to ignore this unknown annotation.
>
> New webrev, keeping @SuppressWarnings("overloads"): http://cr.openjdk.java.net/~clanger/webrevs/8230854.1/
>
> Best regards
> Christoph
>

From david.holmes at oracle.com  Tue Sep 17 23:03:46 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Sep 2019 09:03:46 +1000
Subject: RFR: 8230424: Use platform independent code for Thread.interrupt
 support
In-Reply-To: <e4aa15bc-5154-4ef4-f83e-6e20c03e0294@oracle.com>
References: <dbc0ba11-df77-c804-661b-6928760021d2@oracle.com>
 <e4aa15bc-5154-4ef4-f83e-6e20c03e0294@oracle.com>
Message-ID: <1cb82411-42a5-bf23-555c-0bd02cf7d4e6@oracle.com>

Thanks for the review Dan!

David

On 18/09/2019 12:13 am, Daniel D. Daugherty wrote:
> On 9/13/19 5:12 AM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8230424/webrev/
> 
> src/hotspot/os/posix/os_posix.cpp
>  ??? The old _sleepEvent code had a check for a NULL _SleepEvent
>  ??? before unparking.
>  ??? The old _ParkEvent code had a check for a NULL _ParkEvent
>  ??? before unparking.
> 
>  ??? Update: The code review invite covered this:
> 
>  ????? > - minor cleanups to the logic of interrupt() as we can never
>  ????? >?? have NULL events as we are always guaranteed to be operating
>  ????? >?? on a live thread.
> 
> src/hotspot/os/solaris/os_solaris.cpp
>  ??? No comments.
> 
> src/hotspot/os/windows/osThread_windows.cpp
>  ??? No comments.
> 
> src/hotspot/os/windows/osThread_windows.hpp
>  ??? No comments.
> 
> src/hotspot/os/windows/os_windows.cpp
>  ??? Where did the JSR166 support move to?
>  ??? Update: moved to thread.cpp so okay.
> 
> src/hotspot/share/jvmci/jvmciRuntime.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvm.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvmtiEnv.cpp
>  ??? No comments.
> 
> src/hotspot/share/prims/jvmtiRawMonitor.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/objectMonitor.cpp
>  ??? No comments (the Self -> jt changes threw me for a second :-)).
> 
> src/hotspot/share/runtime/os.hpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/osThread.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/osThread.hpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.cpp
>  ??? No comments.
> 
> src/hotspot/share/runtime/thread.hpp
>  ??? No comments.
> 
> 
> Thumbs up! Robbin flagged the one nit indent issue that I spotted.
> I don't need to see another webrev.
> 
> Dan
> 
> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8230424
>>
>> The next instalment of the interruption logic refactoring.
>>
>> Summary of changes:
>> - the windows-specific actions in os:interrupt and os::is_interrupted 
>> are pushed down into the windows-specific osThread code. This all 
>> relates to the only-used-by-the-JDK _interrupt_event.
>> - the POSIX variant of os::interrupt and os::is_interrupted is inlined 
>> as platform-independent code in the Thread versions and those versions 
>> are themselves moved to JavaThread as instance methods.
>> - minor cleanups to the logic of interrupt() as we can never have NULL 
>> events as we are always guaranteed to be operating on a live thread.
>> - All call sites adjusted as needed.
>>
>> One minor wart in this refactor is that on Windows we will execute an 
>> OrderAccess::release() after setting the interrupt state in the 
>> platform code, and then execute an additional fence() in the shared 
>> code. I don't think this is worth trying to "fix" - and hopefully if 
>> we can get rid of the Windows _interrupt_event this will all go away.
>>
>> If you are wondering why Windows used OrderAccess::release while POSIX 
>> used OrderAccess::fence, I have no idea, and I do not intend to change 
>> either of them. The only safe change would be to use fence() in both 
>> cases, which just makes the Windows wart worse - and unnecessarily so 
>> as we have seen no bugs using the existing release().
>>
>> Testing:
>> ?- hotspot runtime
>> ?- Tiers 1-3
>>
>> Thanks,
>> David
> 

From david.holmes at oracle.com  Wed Sep 18 01:15:57 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Sep 2019 11:15:57 +1000
Subject: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB5078E1670EDB0D342393363E938F0@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078E1670EDB0D342393363E938F0@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <a8beb7da-78f3-efba-3f35-3e4d3ae9d451@oracle.com>

Hi Matthias,

On 18/09/2019 12:18 am, Baesken, Matthias wrote:
> Hello,  while looking at some  atoi usages in the codebase I started to wonder about the  "sun.java.launcher.pid"  property.
> Currently in java_md_solinux.c  the property is set on Linux only  by default (code is guarded #ifdef __linux__ ).
> Later it is passed  to the int  variable _sun_java_launcher_pid (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
> 
> Is the property still supported (one would need to set it from user side on the command line on non-Linux because it is not set by default on bsd/macOS) ?
> Can the coding be removed (or should it enabled for BSD/Mac like we do on Linux) ?
> 
> The os_bsd comment mentiones the bug 6351349 :
> 
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
> JDK-6351349 : On linux with the old thread lib, jps should return the same PID as $!
> 
> but this looks very old.

That was the bug that added this code as it was needed on Linux with 
LinuxThreads. The code was then removed on Linux under

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

The review thread starts here:

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-May/014709.html

I think we were focussed solely on cleaning up the hotspot Linux code 
and didn't really look at the wider implication of the use of 
sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the 
Linux code without giving it any consideration - as you can tell from 
the comment:

   // With BsdThreads the JavaMain thread pid (primordial thread)
   // is different than the pid of the java launcher thread.
   // So, on Bsd, the launcher thread pid is passed to the VM
   // via the sun.java.launcher.pid property.

where you can tell that Linux was simply replaced by Bsd, so we 
reference the non-existent BsdThreads :(

So yes this all seems to be dead code that should be removed - core-libs 
folk will need to be involved of course as they own the launcher. :) It 
looks like SetJavaLauncherPlatformProps() can be removed completely.

Thanks,
David

> Best regards, Matthias
> 
> 
> 
> 
> coding parts mentioned :
> 
> src/hotspot/os/bsd/os_bsd.cpp
> -----------------------------------
> 
> void os::init(void) {
>    char dummy;   // used to get a guess on initial stack address
> 
>    // With BsdThreads the JavaMain thread pid (primordial thread)
>    // is different than the pid of the java launcher thread.
>    // So, on Bsd, the launcher thread pid is passed to the VM
>    // via the sun.java.launcher.pid property.
>    // Use this property instead of getpid() if it was correctly passed.
>    // See bug 6351349.
>    pid_t java_launcher_pid = (pid_t) Arguments::sun_java_launcher_pid();
> 
>    _initial_pid = (java_launcher_pid > 0) ? java_launcher_pid : getpid();
> 
> 
> arguments.cpp / hpp
> ---------------------
> 
>      if (match_option(option, "-Dsun.java.launcher.pid=", &tail)) {
>        _sun_java_launcher_pid = atoi(tail);
>        continue;
>      }
> 
>    static int sun_java_launcher_pid()        { return _sun_java_launcher_pid; }
> 
> 
> java_md_solinux.c
> ---------------------
> 
> void SetJavaLauncherPlatformProps() {
>     /* Linux only */
> #ifdef __linux__
>      const char *substr = "-Dsun.java.launcher.pid=";
>      char *pid_prop_str = (char *)JLI_MemAlloc(JLI_StrLen(substr) + MAX_PID_STR_SZ + 1);
>      sprintf(pid_prop_str, "%s%d", substr, getpid());
>      AddOption(pid_prop_str, NULL);
> #endif /* __linux__ */
> }
> 

From matthias.baesken at sap.com  Wed Sep 18 07:18:02 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 18 Sep 2019 07:18:02 +0000
Subject: sun.java.launcher.pid property usage
In-Reply-To: <a8beb7da-78f3-efba-3f35-3e4d3ae9d451@oracle.com>
References: <AM6PR02MB5078E1670EDB0D342393363E938F0@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a8beb7da-78f3-efba-3f35-3e4d3ae9d451@oracle.com>
Message-ID: <AM6PR02MB50781822365ABE04F86D87BF938E0@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi David, thanks for the additional  information .
I opened  

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

8231171: remove reamining sun.java.launcher.pid references

  to do the additional cleanup .

Best regards, Matthias


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Mittwoch, 18. September 2019 03:16
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: sun.java.launcher.pid property usage
> 
> Hi Matthias,
> 
> On 18/09/2019 12:18 am, Baesken, Matthias wrote:
> > Hello,  while looking at some  atoi usages in the codebase I started to
> wonder about the  "sun.java.launcher.pid"  property.
> > Currently in java_md_solinux.c  the property is set on Linux only  by default
> (code is guarded #ifdef __linux__ ).
> > Later it is passed  to the int  variable _sun_java_launcher_pid
> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
> > However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
> >
> > Is the property still supported (one would need to set it from user side on
> the command line on non-Linux because it is not set by default on
> bsd/macOS) ?
> > Can the coding be removed (or should it enabled for BSD/Mac like we do
> on Linux) ?
> >
> > The os_bsd comment mentiones the bug 6351349 :
> >
> > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
> > JDK-6351349 : On linux with the old thread lib, jps should return the same
> PID as $!
> >
> > but this looks very old.
> 
> That was the bug that added this code as it was needed on Linux with
> LinuxThreads. The code was then removed on Linux under
> 
> https://bugs.openjdk.java.net/browse/JDK-8078513
> 
> The review thread starts here:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-
> May/014709.html
> 
> I think we were focussed solely on cleaning up the hotspot Linux code
> and didn't really look at the wider implication of the use of
> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the
> Linux code without giving it any consideration - as you can tell from
> the comment:
> 
>    // With BsdThreads the JavaMain thread pid (primordial thread)
>    // is different than the pid of the java launcher thread.
>    // So, on Bsd, the launcher thread pid is passed to the VM
>    // via the sun.java.launcher.pid property.
> 
> where you can tell that Linux was simply replaced by Bsd, so we
> reference the non-existent BsdThreads :(
> 
> So yes this all seems to be dead code that should be removed - core-libs
> folk will need to be involved of course as they own the launcher. :) It
> looks like SetJavaLauncherPlatformProps() can be removed completely.
> 
> Thanks,
> David
> 
> > Best regards, Matthias
> >
> >
> >
> >
> > coding parts mentioned :
> >
> > src/hotspot/os/bsd/os_bsd.cpp
> > -----------------------------------
> >
> > void os::init(void) {
> >    char dummy;   // used to get a guess on initial stack address
> >
> >    // With BsdThreads the JavaMain thread pid (primordial thread)
> >    // is different than the pid of the java launcher thread.
> >    // So, on Bsd, the launcher thread pid is passed to the VM
> >    // via the sun.java.launcher.pid property.
> >    // Use this property instead of getpid() if it was correctly passed.
> >    // See bug 6351349.
> >    pid_t java_launcher_pid = (pid_t) Arguments::sun_java_launcher_pid();
> >
> >    _initial_pid = (java_launcher_pid > 0) ? java_launcher_pid : getpid();
> >
> >
> > arguments.cpp / hpp
> > ---------------------
> >
> >      if (match_option(option, "-Dsun.java.launcher.pid=", &tail)) {
> >        _sun_java_launcher_pid = atoi(tail);
> >        continue;
> >      }
> >
> >    static int sun_java_launcher_pid()        { return _sun_java_launcher_pid; }
> >
> >
> > java_md_solinux.c
> > ---------------------
> >
> > void SetJavaLauncherPlatformProps() {
> >     /* Linux only */
> > #ifdef __linux__
> >      const char *substr = "-Dsun.java.launcher.pid=";
> >      char *pid_prop_str = (char *)JLI_MemAlloc(JLI_StrLen(substr) +
> MAX_PID_STR_SZ + 1);
> >      sprintf(pid_prop_str, "%s%d", substr, getpid());
> >      AddOption(pid_prop_str, NULL);
> > #endif /* __linux__ */
> > }
> >

From rkennke at redhat.com  Wed Sep 18 14:46:57 2019
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 18 Sep 2019 16:46:57 +0200
Subject: RFR 8229919: Support JNI Critical functions in object pinning API
 on x86_32 platforms
In-Reply-To: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com>
References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com>
Message-ID: <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com>

Hi Zhengyu,

It looks good to me!

Thanks,
Roman


> Please review this patch that supports JNI critical functions in object 
> pinning capable GCs on x86_32 platforms.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229919
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/
> 
> Test:
>  ? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on Linux 
> x86_64.
>  ? hotspot_gc, hotspot_runtime and hotspot_compiler
>  ? Submit tests in progress.
> 
> Thanks,
> 
> -Zhengyu

From zgu at redhat.com  Wed Sep 18 14:48:06 2019
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 18 Sep 2019 10:48:06 -0400
Subject: RFR 8229919: Support JNI Critical functions in object pinning API
 on x86_32 platforms
In-Reply-To: <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com>
References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com>
 <34499f22-9db4-38d5-abf6-f0aed6c99795@redhat.com>
Message-ID: <bdb7eaf9-2dce-16ec-a2c7-af70125bb6f4@redhat.com>

Thanks, Roman.

-Zhengyu

On 9/18/19 10:46 AM, Roman Kennke wrote:
> Hi Zhengyu,
> 
> It looks good to me!
> 
> Thanks,
> Roman
> 
> 
>> Please review this patch that supports JNI critical functions in 
>> object pinning capable GCs on x86_32 platforms.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229919
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/
>>
>> Test:
>> ?? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on 
>> Linux x86_64.
>> ?? hotspot_gc, hotspot_runtime and hotspot_compiler
>> ?? Submit tests in progress.
>>
>> Thanks,
>>
>> -Zhengyu

From robbin.ehn at oracle.com  Wed Sep 18 15:26:43 2019
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 18 Sep 2019 17:26:43 +0200
Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes
In-Reply-To: <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com>
 <7089f41c-be3e-840b-b640-403d925ac272@oracle.com>
 <0d56d897-5571-ada2-f5f9-95e94d369d22@oracle.com>
Message-ID: <9827442a-bf4a-bf1f-4d45-c88984fc2d3a@oracle.com>

Hi,

So I have a few reviews and if no one else wants to have a look, I'll push tomorrow.
Let me know if you need more time or have any other concerns.

Did a pass through t5-7 and KS-24h-stress.

Thanks, Robbin

On 2019-09-12 13:21, Robbin Ehn wrote:
> Hi, here is v3, addressing Patricio's and Dan's review comments.
> 
> Inc:
> http://cr.openjdk.java.net/~rehn/8226705/v3/inc/webrev/
> 
> Full:
> http://cr.openjdk.java.net/~rehn/8226705/v3/full/webrev/
> 
> Passed t1-5, doing some more testing also.
> 
> Thanks, Robbin
> 
> On 8/28/19 11:57 AM, Robbin Ehn wrote:
>> Hi, hotspot-dev was the intended list.
>>
>> Thanks, Robbin
>>
>> On 2019-08-28 09:30, Robbin Ehn wrote:
>>> Hi all, please consider,
>>>
>>> To get away from the issues of us revoking in the handshake, but before deopt
>>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt
>>> handler.
>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after
>>> that but before we start looking at the monitors, with a NoSafepointVerifier.
>>>
>>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts
>>> some pieces did not apply:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/
>>> So this is what was reviewed.
>>>
>>> The rebase (merge conflict resolutions) and 8224795 bug fix :
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/
>>>
>>> Bug 8224795 fix is here:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html 
>>>
>>>
>>> After this we have the same functionally as the reverted change-set.
>>>
>>> Here is the changes for doing the revoke in deopt handler instead:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/
>>>
>>> This code was messy adding the deopt revocation in 3 places made it worse.
>>> Here is a refactoring of that code. (also removed a dead method in 
>>> biasedlocking):
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/
>>>
>>> And here is full:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/
>>>
>>> Also a full squashed patch file:
>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch
>>>
>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still
>>> running.
>>>
>>> Thanks, Robbin
>>>
>>>

From navy.xliu at gmail.com  Wed Sep 18 18:13:21 2019
From: navy.xliu at gmail.com (Liu Xin)
Date: Wed, 18 Sep 2019 11:13:21 -0700
Subject: hotspot compiler test failed
Message-ID: <CAHPdc0mk92Erqt0G2P+0XV9iTkv9JQ8dW5_xVez_BOCA70TLaQ@mail.gmail.com>

hi, Developers,

our CI detects a failure last night. The setup of test is like this. it's
suggestion from Kozlov.

make test TEST="jtreg:test/hotspot/jtreg/compiler"
JTREG="VERBOSE=nopass;VM_OPTIONS=-Xcomp -ea -esa -XX:CompileThreshold=100
-XX:-TieredCompilation"

There're two commits in that build.
https://github.com/openjdk/jdk/commit/f94f7f2212587a1888a1ae34bdfc00ba059e31c0
https://github.com/openjdk/jdk/commit/5bca86f9f46b65060b220e7e7a3322bf20f94c1d

error message as follows:

Running test 'jtreg:test/hotspot/jtreg/compiler'
--------------------------------------------------
TEST: compiler/jvmci/compilerToVM/DebugOutputTest.java
TEST RESULT: Error. Program `/build/images/jdk/bin/java' timed out (timeout
set to 480000ms, elapsed time including timeout handling was 633049ms).
--------------------------------------------------
Test results: passed: 925; error: 1
Report written to
/build/test-results/jtreg_test_hotspot_jtreg_compiler/html/report.html
Results written to /build/test-support/jtreg_test_hotspot_jtreg_compiler
Error: Some tests failed or other problems occurred.
Finished running test 'jtreg:test/hotspot/jtreg/compiler'
Test report is stored in
/build/test-results/jtreg_test_hotspot_jtreg_compiler

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL
ERROR
>> jtreg:test/hotspot/jtreg/compiler                   926   925     0
1 <<
==============================
TEST FAILURE

From kim.barrett at oracle.com  Wed Sep 18 18:47:34 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 18 Sep 2019 14:47:34 -0400
Subject: hotspot compiler test failed
In-Reply-To: <CAHPdc0mk92Erqt0G2P+0XV9iTkv9JQ8dW5_xVez_BOCA70TLaQ@mail.gmail.com>
References: <CAHPdc0mk92Erqt0G2P+0XV9iTkv9JQ8dW5_xVez_BOCA70TLaQ@mail.gmail.com>
Message-ID: <E6F4B705-3B20-445B-B173-4CB6C0789B50@oracle.com>

> On Sep 18, 2019, at 2:13 PM, Liu Xin <navy.xliu at gmail.com> wrote:
> 
> hi, Developers,
> 
> our CI detects a failure last night. The setup of test is like this. it's
> suggestion from Kozlov.
> 
> make test TEST="jtreg:test/hotspot/jtreg/compiler"
> JTREG="VERBOSE=nopass;VM_OPTIONS=-Xcomp -ea -esa -XX:CompileThreshold=100
> -XX:-TieredCompilation"
> 
> There're two commits in that build.
> https://github.com/openjdk/jdk/commit/f94f7f2212587a1888a1ae34bdfc00ba059e31c0
> https://github.com/openjdk/jdk/commit/5bca86f9f46b65060b220e7e7a3322bf20f94c1d

The second of those commits is JDK-8230424, which has some fallout: JDK-8231162.
Possibly a similar problem?

> error message as follows:
> 
> Running test 'jtreg:test/hotspot/jtreg/compiler'
> --------------------------------------------------
> TEST: compiler/jvmci/compilerToVM/DebugOutputTest.java
> TEST RESULT: Error. Program `/build/images/jdk/bin/java' timed out (timeout
> set to 480000ms, elapsed time including timeout handling was 633049ms).
> --------------------------------------------------
> Test results: passed: 925; error: 1
> Report written to
> /build/test-results/jtreg_test_hotspot_jtreg_compiler/html/report.html
> Results written to /build/test-support/jtreg_test_hotspot_jtreg_compiler
> Error: Some tests failed or other problems occurred.
> Finished running test 'jtreg:test/hotspot/jtreg/compiler'
> Test report is stored in
> /build/test-results/jtreg_test_hotspot_jtreg_compiler
> 
> ==============================
> Test summary
> ==============================
>   TEST                                              TOTAL  PASS  FAIL
> ERROR
>>> jtreg:test/hotspot/jtreg/compiler                   926   925     0
> 1 <<
> ==============================
> TEST FAILURE

From matthias.baesken at sap.com  Thu Sep 19 06:57:37 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 19 Sep 2019 06:57:37 +0000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references  -
 was  RE: sun.java.launcher.pid property usage
Message-ID: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello, as discussed below ,   I want to cleanup  some older references to sun.java.launcher.pid.
Please review the following change.

After removal  of some code belonging  old  LinuxThreads   (JDK-8078513)   , the   sun.java.launcher.pid   handling code remained  but
 seems to be  obsolete these days .

Bug/webrev :

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

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

Best regards, Matthias


> 
> Hi David, thanks for the additional  information .
> I opened
> 
> https://bugs.openjdk.java.net/browse/JDK-8231171
> 
> 8231171: remove reamining sun.java.launcher.pid references
> 
>   to do the additional cleanup .
> 
> Best regards, Matthias
> 
> 
> > -----Original Message-----
> > From: David Holmes <david.holmes at oracle.com>
> > Sent: Mittwoch, 18. September 2019 03:16
> > To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> > dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> > Subject: Re: sun.java.launcher.pid property usage
> >
> > Hi Matthias,
> >
> > On 18/09/2019 12:18 am, Baesken, Matthias wrote:
> > > Hello,  while looking at some  atoi usages in the codebase I started to
> > wonder about the  "sun.java.launcher.pid"  property.
> > > Currently in java_md_solinux.c  the property is set on Linux only  by
> default
> > (code is guarded #ifdef __linux__ ).
> > > Later it is passed  to the int  variable _sun_java_launcher_pid
> > (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
> > > However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
> > >
> > > Is the property still supported (one would need to set it from user side on
> > the command line on non-Linux because it is not set by default on
> > bsd/macOS) ?
> > > Can the coding be removed (or should it enabled for BSD/Mac like we do
> > on Linux) ?
> > >
> > > The os_bsd comment mentiones the bug 6351349 :
> > >
> > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
> > > JDK-6351349 : On linux with the old thread lib, jps should return the same
> > PID as $!
> > >
> > > but this looks very old.
> >
> > That was the bug that added this code as it was needed on Linux with
> > LinuxThreads. The code was then removed on Linux under
> >
> > https://bugs.openjdk.java.net/browse/JDK-8078513
> >
> > The review thread starts here:
> >
> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-
> > May/014709.html
> >
> > I think we were focussed solely on cleaning up the hotspot Linux code
> > and didn't really look at the wider implication of the use of
> > sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the
> > Linux code without giving it any consideration - as you can tell from
> > the comment:
> >
> >    // With BsdThreads the JavaMain thread pid (primordial thread)
> >    // is different than the pid of the java launcher thread.
> >    // So, on Bsd, the launcher thread pid is passed to the VM
> >    // via the sun.java.launcher.pid property.
> >
> > where you can tell that Linux was simply replaced by Bsd, so we
> > reference the non-existent BsdThreads :(
> >
> > So yes this all seems to be dead code that should be removed - core-libs
> > folk will need to be involved of course as they own the launcher. :) It
> > looks like SetJavaLauncherPlatformProps() can be removed completely.
> >
> > Thanks,
> > David


From Alan.Bateman at oracle.com  Thu Sep 19 07:01:50 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Sep 2019 08:01:50 +0100
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <dd944a80-26f6-6602-8a27-8a0a331424fc@oracle.com>

On 19/09/2019 07:57, Baesken, Matthias wrote:
> Hello, as discussed below ,   I want to cleanup  some older references to sun.java.launcher.pid.
> Please review the following change.
>
> After removal  of some code belonging  old  LinuxThreads   (JDK-8078513)   , the   sun.java.launcher.pid   handling code remained  but
>   seems to be  obsolete these days .
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8231171
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/
>
The removal from the java launcher looks okay.

-Alan.

From david.holmes at oracle.com  Thu Sep 19 08:55:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Sep 2019 18:55:47 +1000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>

Hi Matthias,

Thanks for cleaning this up.

On 19/09/2019 4:57 pm, Baesken, Matthias wrote:
> Hello, as discussed below ,   I want to cleanup  some older references to sun.java.launcher.pid.
> Please review the following change.
> 
> After removal  of some code belonging  old  LinuxThreads   (JDK-8078513)   , the   sun.java.launcher.pid   handling code remained  but
>   seems to be  obsolete these days .
> 
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8231171
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/

src/hotspot/os/bsd/os_bsd.cpp

Can you delete the entire comment block here:

1126   // Under the old bsd thread library, bsd gives each thread
...
1140   // OSThread::thread_id() method in osThread_bsd.hpp file

as it was simply copied from Linux and is nonsense on BSD.

Otherwise that all looks good to me. No need for an updated webrev.

Thanks,
David
-----

> Best regards, Matthias
> 
> 
>>
>> Hi David, thanks for the additional  information .
>> I opened
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231171
>>
>> 8231171: remove reamining sun.java.launcher.pid references
>>
>>    to do the additional cleanup .
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: David Holmes <david.holmes at oracle.com>
>>> Sent: Mittwoch, 18. September 2019 03:16
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: sun.java.launcher.pid property usage
>>>
>>> Hi Matthias,
>>>
>>> On 18/09/2019 12:18 am, Baesken, Matthias wrote:
>>>> Hello,  while looking at some  atoi usages in the codebase I started to
>>> wonder about the  "sun.java.launcher.pid"  property.
>>>> Currently in java_md_solinux.c  the property is set on Linux only  by
>> default
>>> (code is guarded #ifdef __linux__ ).
>>>> Later it is passed  to the int  variable _sun_java_launcher_pid
>>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
>>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
>>>>
>>>> Is the property still supported (one would need to set it from user side on
>>> the command line on non-Linux because it is not set by default on
>>> bsd/macOS) ?
>>>> Can the coding be removed (or should it enabled for BSD/Mac like we do
>>> on Linux) ?
>>>>
>>>> The os_bsd comment mentiones the bug 6351349 :
>>>>
>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
>>>> JDK-6351349 : On linux with the old thread lib, jps should return the same
>>> PID as $!
>>>>
>>>> but this looks very old.
>>>
>>> That was the bug that added this code as it was needed on Linux with
>>> LinuxThreads. The code was then removed on Linux under
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8078513
>>>
>>> The review thread starts here:
>>>
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-
>>> May/014709.html
>>>
>>> I think we were focussed solely on cleaning up the hotspot Linux code
>>> and didn't really look at the wider implication of the use of
>>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from the
>>> Linux code without giving it any consideration - as you can tell from
>>> the comment:
>>>
>>>     // With BsdThreads the JavaMain thread pid (primordial thread)
>>>     // is different than the pid of the java launcher thread.
>>>     // So, on Bsd, the launcher thread pid is passed to the VM
>>>     // via the sun.java.launcher.pid property.
>>>
>>> where you can tell that Linux was simply replaced by Bsd, so we
>>> reference the non-existent BsdThreads :(
>>>
>>> So yes this all seems to be dead code that should be removed - core-libs
>>> folk will need to be involved of course as they own the launcher. :) It
>>> looks like SetJavaLauncherPlatformProps() can be removed completely.
>>>
>>> Thanks,
>>> David
> 

From sgehwolf at redhat.com  Thu Sep 19 14:20:10 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Sep 2019 16:20:10 +0200
Subject: RFR: 8230848: OSContainer: Refactor container detection code
Message-ID: <d42aa579c59e2ac5fcca9b43856f0759d1949578.camel@redhat.com>

Hi,

Please review this code refactoring which will help getting a cgroups
v2 implementation for OSContainer implemented. The proposed changes are
mentioned in the bug. In essence, after this patch only methods
actually called in os_linux.cpp are exposed via OSContainer. Everything
else remains an implementation detail. After this refactoring it should
also be clearer what the actual bits implemented via cgroups v1 are in
hotspot. Functionally there should be no difference before and after
this patch.

If you are curious where I'm going with this, have a look at JDK-
8230305 which has a draft of an implementation of cgroups v2 building
on top of this patch.

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

Testing: jdk-submit, tier1 tests on Linux x86_64, container tests
         with docker and podman.

Thoughts?

Thanks,
Severin


From christoph.langer at sap.com  Thu Sep 19 21:54:47 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Sep 2019 21:54:47 +0000
Subject: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove
 noisy traces in StreamPumper
In-Reply-To: <5d947cc5-171c-18fb-a33f-0bed7eeeb970@oracle.com>
References: <AM6PR02MB5192ED5A78DF883A67C9EBC98AB10@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <470150f4-3c8d-a585-4bc5-5b3bfb58dc01@oracle.com>
 <AM6PR02MB5192793CA1E8AC118FD1D1DA8AB00@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <c2a4d875-2b61-ab08-9274-d158308cec14@oracle.com>
 <AM6PR02MB51921DE73ACDE7BA755CC2D68AB30@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5d947cc5-171c-18fb-a33f-0bed7eeeb970@oracle.com>
Message-ID: <AM6PR02MB51922AA13A0013D6A551EA168A890@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Joe,

thanks for looking into that. Seems like a good idea to update jls-9.6.4.5 then.

Best regards
Christoph

From: Joe Darcy <joe.darcy at oracle.com>
Sent: Dienstag, 17. September 2019 22:01
To: Langer, Christoph <christoph.langer at sap.com>; David Holmes <david.holmes at oracle.com>; hotspot-dev at openjdk.java.net
Subject: Re: RFR (S): 8230854: Cleanup SuppressWarnings in test lib and remove noisy traces in StreamPumper


Hello,

The specification for the SuppressWarnings type states:

"The presence of unrecognized warning names is not an error: Compilers must ignore any warning names they do not recognize. They are, however, free to emit a warning if an annotation contains an unrecognized warning name."
https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/lang/SuppressWarnings.html#value()

Note that the JLS does not repeat this requirement of compilers in its section on @SuppressWarnings:

    https://docs.oracle.com/javase/specs/jls/se13/html/jls-9.html#jls-9.6.4.5

I've filed JDK-8231147 for this issue.

HTH,

-Joe
On 9/13/2019 1:04 AM, Langer, Christoph wrote:

Hi David,



test/lib/jdk/test/lib/process/ProcessTools.java



-     @SuppressWarnings("overloads")

        public static Process startProcess(String name,

                                           ProcessBuilder processBuilder,

                                           final Predicate<String>

linePredicate)



Unnecessary? I can't find what this warning is supposed to mean. Is it used by some IDE's?

I didn't find any reference either and the IDE says that this is an unknown

annotation. So unless somebody steps up and tells us what it's good for, I guess it can be removed.



Not it is a valid warning. Try compiling with -Xlint:all without the

warning suppressed:



----------System.err:(19/1295)----------

/scratch/users/daholme/jdk-

dev2/open/test/lib/jdk/test/lib/process/ProcessTools.java:91:

warning: [overloads]

startProcess(String,ProcessBuilder,Consumer<String>) in ProcessTools is

potentially ambiguous with

startProcess(String,ProcessBuilder,Predicate<String>) in ProcessTools

     public static Process startProcess(String name,

                           ^



Thanks for taking a closer look here and enlightening me.



@SuppressWarnings("overloads") is supported by javac but not by my Eclipse IDE. One can list supported @SuppressWarnings types with javac -X. You'll get:

overloads            Warn about issues regarding method overloads.



So I now understand what the warning means and why @SuppressWarnings("overloads") is required here. I've also configured my Eclipse to ignore this unknown annotation.



New webrev, keeping @SuppressWarnings("overloads"): http://cr.openjdk.java.net/~clanger/webrevs/8230854.1/



Best regards

Christoph



From matthias.baesken at sap.com  Fri Sep 20 07:03:33 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 20 Sep 2019 07:03:33 +0000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
Message-ID: <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>


Hello,  looks like   on Linux  there is a special check   in TestSpecialArgs.java  for 

    launcherPidString = "launcher.pid="    

that  fails after   8231171  .
Should I adjust the test ?  Or  keep the  setting in the launcher on Linux ?  


tools/launcher/TestSpecialArgs.java


        /*
         * On Linux, Launcher Tracking will print the PID.  Use this info
         * to validate what we got as the PID in the Launcher itself.
         * Linux is the only one that prints this, and trying to get it
         * here for win is awful.  So let the linux test make sure we get
         * the valid pid, and for non-linux, just make sure pid string is
         * non-zero.
         */
        if (isLinux) {
                 . . . . .
            if (launcherPid == null) {
                System.out.println(tr);
                throw new RuntimeException("Error: failed to find launcher Pid in launcher tracking info");
            }
      ...

Exception  thrown by the test  :


----begin detailed exceptions----
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at TestHelper.run(TestHelper.java:202)
	at TestSpecialArgs.main(TestSpecialArgs.java:44)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.lang.RuntimeException: Error: failed to find launcher Pid in launcher tracking info
	at TestSpecialArgs.testNativeMemoryTracking(TestSpecialArgs.java:193)
	... 12 more


Best regards, Matthias



> 
> Hi Matthias,
> 
> Thanks for cleaning this up.
> 
> On 19/09/2019 4:57 pm, Baesken, Matthias wrote:
> > Hello, as discussed below ,   I want to cleanup  some older references to
> sun.java.launcher.pid.
> > Please review the following change.
> >
> > After removal  of some code belonging  old  LinuxThreads   (JDK-8078513)   ,
> the   sun.java.launcher.pid   handling code remained  but
> >   seems to be  obsolete these days .
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8231171
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/
> 
> src/hotspot/os/bsd/os_bsd.cpp
> 
> Can you delete the entire comment block here:
> 
> 1126   // Under the old bsd thread library, bsd gives each thread
> ...
> 1140   // OSThread::thread_id() method in osThread_bsd.hpp file
> 
> as it was simply copied from Linux and is nonsense on BSD.
> 
> Otherwise that all looks good to me. No need for an updated webrev.
> 
> Thanks,
> David
> -----
> 
> > Best regards, Matthias
> >
> >
> >>
> >> Hi David, thanks for the additional  information .
> >> I opened
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8231171
> >>
> >> 8231171: remove reamining sun.java.launcher.pid references
> >>
> >>    to do the additional cleanup .
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> -----Original Message-----
> >>> From: David Holmes <david.holmes at oracle.com>
> >>> Sent: Mittwoch, 18. September 2019 03:16
> >>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> >>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> >>> Subject: Re: sun.java.launcher.pid property usage
> >>>
> >>> Hi Matthias,
> >>>
> >>> On 18/09/2019 12:18 am, Baesken, Matthias wrote:
> >>>> Hello,  while looking at some  atoi usages in the codebase I started to
> >>> wonder about the  "sun.java.launcher.pid"  property.
> >>>> Currently in java_md_solinux.c  the property is set on Linux only  by
> >> default
> >>> (code is guarded #ifdef __linux__ ).
> >>>> Later it is passed  to the int  variable _sun_java_launcher_pid
> >>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
> >>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
> >>>>
> >>>> Is the property still supported (one would need to set it from user side
> on
> >>> the command line on non-Linux because it is not set by default on
> >>> bsd/macOS) ?
> >>>> Can the coding be removed (or should it enabled for BSD/Mac like we
> do
> >>> on Linux) ?
> >>>>
> >>>> The os_bsd comment mentiones the bug 6351349 :
> >>>>
> >>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
> >>>> JDK-6351349 : On linux with the old thread lib, jps should return the
> same
> >>> PID as $!
> >>>>
> >>>> but this looks very old.
> >>>
> >>> That was the bug that added this code as it was needed on Linux with
> >>> LinuxThreads. The code was then removed on Linux under
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8078513
> >>>
> >>> The review thread starts here:
> >>>
> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-
> >>> May/014709.html
> >>>
> >>> I think we were focussed solely on cleaning up the hotspot Linux code
> >>> and didn't really look at the wider implication of the use of
> >>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from
> the
> >>> Linux code without giving it any consideration - as you can tell from
> >>> the comment:
> >>>
> >>>     // With BsdThreads the JavaMain thread pid (primordial thread)
> >>>     // is different than the pid of the java launcher thread.
> >>>     // So, on Bsd, the launcher thread pid is passed to the VM
> >>>     // via the sun.java.launcher.pid property.
> >>>
> >>> where you can tell that Linux was simply replaced by Bsd, so we
> >>> reference the non-existent BsdThreads :(
> >>>
> >>> So yes this all seems to be dead code that should be removed - core-libs
> >>> folk will need to be involved of course as they own the launcher. :) It
> >>> looks like SetJavaLauncherPlatformProps() can be removed completely.
> >>>
> >>> Thanks,
> >>> David
> >

From david.holmes at oracle.com  Fri Sep 20 08:11:09 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Sep 2019 18:11:09 +1000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
 <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>

Hi Matthias,

On 20/09/2019 5:03 pm, Baesken, Matthias wrote:
> 
> Hello,  looks like   on Linux  there is a special check   in TestSpecialArgs.java  for
> 
>      launcherPidString = "launcher.pid="
> 
> that  fails after   8231171  .
> Should I adjust the test ?  Or  keep the  setting in the launcher on Linux ?

IMHO adjust the test please.

Thanks,
David
-----

> 
> tools/launcher/TestSpecialArgs.java
> 
> 
>          /*
>           * On Linux, Launcher Tracking will print the PID.  Use this info
>           * to validate what we got as the PID in the Launcher itself.
>           * Linux is the only one that prints this, and trying to get it
>           * here for win is awful.  So let the linux test make sure we get
>           * the valid pid, and for non-linux, just make sure pid string is
>           * non-zero.
>           */
>          if (isLinux) {
>                   . . . . .
>              if (launcherPid == null) {
>                  System.out.println(tr);
>                  throw new RuntimeException("Error: failed to find launcher Pid in launcher tracking info");
>              }
>        ...
> 
> Exception  thrown by the test  :
> 
> 
> ----begin detailed exceptions----
> java.lang.reflect.InvocationTargetException
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at TestHelper.run(TestHelper.java:202)
> 	at TestSpecialArgs.main(TestSpecialArgs.java:44)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:830)
> Caused by: java.lang.RuntimeException: Error: failed to find launcher Pid in launcher tracking info
> 	at TestSpecialArgs.testNativeMemoryTracking(TestSpecialArgs.java:193)
> 	... 12 more
> 
> 
> Best regards, Matthias
> 
> 
> 
>>
>> Hi Matthias,
>>
>> Thanks for cleaning this up.
>>
>> On 19/09/2019 4:57 pm, Baesken, Matthias wrote:
>>> Hello, as discussed below ,   I want to cleanup  some older references to
>> sun.java.launcher.pid.
>>> Please review the following change.
>>>
>>> After removal  of some code belonging  old  LinuxThreads   (JDK-8078513)   ,
>> the   sun.java.launcher.pid   handling code remained  but
>>>    seems to be  obsolete these days .
>>>
>>> Bug/webrev :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231171
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.0/
>>
>> src/hotspot/os/bsd/os_bsd.cpp
>>
>> Can you delete the entire comment block here:
>>
>> 1126   // Under the old bsd thread library, bsd gives each thread
>> ...
>> 1140   // OSThread::thread_id() method in osThread_bsd.hpp file
>>
>> as it was simply copied from Linux and is nonsense on BSD.
>>
>> Otherwise that all looks good to me. No need for an updated webrev.
>>
>> Thanks,
>> David
>> -----
>>
>>> Best regards, Matthias
>>>
>>>
>>>>
>>>> Hi David, thanks for the additional  information .
>>>> I opened
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8231171
>>>>
>>>> 8231171: remove reamining sun.java.launcher.pid references
>>>>
>>>>     to do the additional cleanup .
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes <david.holmes at oracle.com>
>>>>> Sent: Mittwoch, 18. September 2019 03:16
>>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
>>>>> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>>> Subject: Re: sun.java.launcher.pid property usage
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> On 18/09/2019 12:18 am, Baesken, Matthias wrote:
>>>>>> Hello,  while looking at some  atoi usages in the codebase I started to
>>>>> wonder about the  "sun.java.launcher.pid"  property.
>>>>>> Currently in java_md_solinux.c  the property is set on Linux only  by
>>>> default
>>>>> (code is guarded #ifdef __linux__ ).
>>>>>> Later it is passed  to the int  variable _sun_java_launcher_pid
>>>>> (arguments.cpp) and can be retrieved by sun_java_launcher_pid() .
>>>>>> However only in src/hotspot/os/bsd/os_bsd.cpp it is really used.
>>>>>>
>>>>>> Is the property still supported (one would need to set it from user side
>> on
>>>>> the command line on non-Linux because it is not set by default on
>>>>> bsd/macOS) ?
>>>>>> Can the coding be removed (or should it enabled for BSD/Mac like we
>> do
>>>>> on Linux) ?
>>>>>>
>>>>>> The os_bsd comment mentiones the bug 6351349 :
>>>>>>
>>>>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6351349
>>>>>> JDK-6351349 : On linux with the old thread lib, jps should return the
>> same
>>>>> PID as $!
>>>>>>
>>>>>> but this looks very old.
>>>>>
>>>>> That was the bug that added this code as it was needed on Linux with
>>>>> LinuxThreads. The code was then removed on Linux under
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8078513
>>>>>
>>>>> The review thread starts here:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-
>>>>> May/014709.html
>>>>>
>>>>> I think we were focussed solely on cleaning up the hotspot Linux code
>>>>> and didn't really look at the wider implication of the use of
>>>>> sun.java.launcher.pid. The code in os_bsd.cpp was simply copied from
>> the
>>>>> Linux code without giving it any consideration - as you can tell from
>>>>> the comment:
>>>>>
>>>>>      // With BsdThreads the JavaMain thread pid (primordial thread)
>>>>>      // is different than the pid of the java launcher thread.
>>>>>      // So, on Bsd, the launcher thread pid is passed to the VM
>>>>>      // via the sun.java.launcher.pid property.
>>>>>
>>>>> where you can tell that Linux was simply replaced by Bsd, so we
>>>>> reference the non-existent BsdThreads :(
>>>>>
>>>>> So yes this all seems to be dead code that should be removed - core-libs
>>>>> folk will need to be involved of course as they own the launcher. :) It
>>>>> looks like SetJavaLauncherPlatformProps() can be removed completely.
>>>>>
>>>>> Thanks,
>>>>> David
>>>

From matthias.baesken at sap.com  Fri Sep 20 09:14:39 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 20 Sep 2019 09:14:39 +0000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
 <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>
Message-ID: <AM6PR02MB507864D0EB71CA0F9B6BE6CA93880@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi David   , I adjusted the  test  ( test/jdk/tools/launcher/TestSpecialArgs.java )   and removed the comments  in os_bsd.cpp  (suggested by you) .
New webrev :

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

Best regards, Matthias




> Hi Matthias,
> 
> On 20/09/2019 5:03 pm, Baesken, Matthias wrote:
> >
> > Hello,  looks like   on Linux  there is a special check   in TestSpecialArgs.java
> for
> >
> >      launcherPidString = "launcher.pid="
> >
> > that  fails after   8231171  .
> > Should I adjust the test ?  Or  keep the  setting in the launcher on Linux ?
> 
> IMHO adjust the test please.
> 
> Thanks,
> David
> -----
> 


From david.holmes at oracle.com  Fri Sep 20 09:41:04 2019
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Sep 2019 19:41:04 +1000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB507864D0EB71CA0F9B6BE6CA93880@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
 <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>
 <AM6PR02MB507864D0EB71CA0F9B6BE6CA93880@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com>

That looks fine to me.

Thanks,
David

On 20/09/2019 7:14 pm, Baesken, Matthias wrote:
> Hi David   , I adjusted the  test  ( test/jdk/tools/launcher/TestSpecialArgs.java )   and removed the comments  in os_bsd.cpp  (suggested by you) .
> New webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/
> 
> Best regards, Matthias
> 
> 
> 
> 
>> Hi Matthias,
>>
>> On 20/09/2019 5:03 pm, Baesken, Matthias wrote:
>>>
>>> Hello,  looks like   on Linux  there is a special check   in TestSpecialArgs.java
>> for
>>>
>>>       launcherPidString = "launcher.pid="
>>>
>>> that  fails after   8231171  .
>>> Should I adjust the test ?  Or  keep the  setting in the launcher on Linux ?
>>
>> IMHO adjust the test please.
>>
>> Thanks,
>> David
>> -----
>>
> 

From rwestrel at redhat.com  Fri Sep 20 14:20:07 2019
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 20 Sep 2019 16:20:07 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <dea45bda-6b96-c758-d104-dbeb28d27aeb@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
 <dea45bda-6b96-c758-d104-dbeb28d27aeb@oracle.com>
Message-ID: <875zlnhwx4.fsf@redhat.com>


> http://cr.openjdk.java.net/~thartmann/8231058/webrev.00/

Looks good to me.

Roland.

From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 21 15:16:06 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 21 Sep 2019 17:16:06 +0200
Subject: Multiple this$1 fields when mixing subclassing and inner classes
In-Reply-To: <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
References: <CAC2-jLEuzfxjrjqDQ-=qwXijbG1t_SuwvNo0Jn9ts_ukVs0Y_g@mail.gmail.com>
 <CAC2-jLHLzGy9egkh_muDWeUUYf9GMOV4WPng5EqPyXFU62EPvw@mail.gmail.com>
 <4c517999-dcd9-e16c-68f7-4ec661c3642a@oracle.com>
 <CAC2-jLFsJJMLGcqtTQZMNwepKM+tWXPLz_6_rHvJO24q0R920Q@mail.gmail.com>
 <42159c7a-0a0a-70e6-9cd8-fb4a1e3710ec@oracle.com>
 <CAC2-jLG4ZOxDgio0JQvCR1PnHOExcCWtDKqc58ZwagxmVoNujA@mail.gmail.com>
 <8d553b94-9cd3-2e03-e98b-8e521c109e36@oracle.com>
Message-ID: <CAC2-jLHjVucSqiA3KQQDNcuk-wz0B2pkPOTonm0SkDn26CvoiQ@mail.gmail.com>

I thought about it some more and I think it is theoretically possible. You
just compile the invokespecial statements on the "magic" this$1 field into
something involving a cast.

That cast does have to be a checked one, because in the presence of
reflection, we can't guarantee that this$1 has the correct (formally
undeclared) subtype. So it involves a performance degradation.

Or you move that degradation to Field.set() which would have to check for
this special case. Sounds nasty too. It would probably slow down every
single Field.set() on any field which is rather not acceptable.

In effect, we'd have a field that does not have its declared type, but,
when the whole class is subclased, only allows a certain subtype.

All in all, I guess it's not worth doing. But that wasted space of a
doubled reference to the same object just irks me :-D

Regarding the bureaucracy, I think I'll actually sign the OCA. Maybe I'll
need it at some point...

It's not like in the old Sun days where you had to be careful to never have
looked at "classified" parts of the JDK if you wanted to re-implement parts
of it yourself, is it? I remember this being an issue in the JOS project
back in the day. ("Clean-room implementations.") I don't remember exactly
what the subprojects were, but people were so hyped about Java, they
basically wanted to make their own clones of it.

On Tue, 10 Sep 2019 at 01:17, David Holmes <david.holmes at oracle.com> wrote:

> On 10/09/2019 9:09 am, Stefan Reich wrote:
> >     But you're not talking about bytecode here you're talking about
> inside
> >     the VM. If there is an invokespecial on this$1 of type A then the
> >     constant pool lookup of its type will be A and we will resolve the
> call
> >     based on A's methods. If it were of type B then the resolution
> process
> >     would be different. There's nowhere to "insert a cast" here.
> >
> >
> > Can invokespecials on this$0/this$1 happen? I'm struggling to imagine a
> > case for this.
> >
> > invokespecial invokes private instance methods, superclass methods or
> > constructors. Superclass methods don't apply, neither do constructors.
> > And calls to private methods happen through bridges (just verified this
> > for myself again :):
> >
> >        13: aload_0
> >        14: getfield      #1                  // Field this$0:Lbla;
> >        17: invokestatic  #4                  // Method
> > bla.access$000:(Lbla;)V
> >
> > So what remains?
>
> This changed in JDK 11 with the addition of nestmates. Now inner classes
> have direct private access, no bridges needed, and we use invokespecial
> or invokevirtual as appropriate. For private methods invokevirtual is
> mainly used now, but of course we don't do virtual dispatch - there are
> special rules for private method resolution and selection.
>
> class A {
>    void m() {}
>    class InnerA {
>      void callM() { m(); }
>    }
> }
>
>   void callM();
>      descriptor: ()V
>      flags: (0x0000)
>      Code:
>        stack=1, locals=1, args_size=1
>           0: aload_0
>           1: getfield      #1                  // Field this$0:LA;
>           4: invokevirtual #13                 // Method A.m:()V
>           7: return
>        LineNumberTable:
>          line 4: 0
>
> >     BTW what introspection tool did you use to show this?
> >
> > My own tools ("JavaX")... here's the example program:
> > http://code.botcompany.de/1025166
>
> Thanks for the pointer.
>
> Cheers,
> David
>
> > Many greetings :)
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Sat Sep 21 15:38:27 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Sat, 21 Sep 2019 17:38:27 +0200
Subject: About the OCA
Message-ID: <CAC2-jLEL1PyerBzemS-0BCae361soNxO=jvmRNMoL8GGtPTSEg@mail.gmail.com>

Legalese is always scary. But as I read it, it only applies to how what I
explicitly decide to contribute to an Oracle project is handled, right?
Basically, I just grant Oracle a non-exclusive license to redistribute
code, and protect the company from any kind of lawsuit related to the code.
Is that correct?

-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From joe.darcy at oracle.com  Sat Sep 21 21:27:17 2019
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 21 Sep 2019 14:27:17 -0700
Subject: About the OCA
In-Reply-To: <CAC2-jLEL1PyerBzemS-0BCae361soNxO=jvmRNMoL8GGtPTSEg@mail.gmail.com>
References: <CAC2-jLEL1PyerBzemS-0BCae361soNxO=jvmRNMoL8GGtPTSEg@mail.gmail.com>
Message-ID: <fd25e782-7028-4492-3f8d-2f078ee45a4a@oracle.com>

See the OpenJDK legal (http://openjdk.java.net/legal/) FAQ:

 ??? https://www.oracle.com/technetwork/oca-faq-405384.pdf

HTH,

-Joe

On 9/21/2019 8:38 AM, Stefan Reich wrote:
> Legalese is always scary. But as I read it, it only applies to how what I
> explicitly decide to contribute to an Oracle project is handled, right?
> Basically, I just grant Oracle a non-exclusive license to redistribute
> code, and protect the company from any kind of lawsuit related to the code.
> Is that correct?
>

From glaubitz at physik.fu-berlin.de  Sun Sep 22 08:19:07 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sun, 22 Sep 2019 10:19:07 +0200
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
Message-ID: <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>

On 9/7/19 12:44 AM, John Paul Adrian Glaubitz wrote:
> In addition to the build failure of the server VM with gcc-9, Zero is affected as
> well, but here it's not a syntax issue but the VM is segfaulting when built with
> gcc-9.
> 
> Backtrace is below. Any suggestions?
Reported to gcc upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From tobias.hartmann at oracle.com  Mon Sep 23 04:55:36 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 23 Sep 2019 06:55:36 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <875zlnhwx4.fsf@redhat.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
 <dea45bda-6b96-c758-d104-dbeb28d27aeb@oracle.com> <875zlnhwx4.fsf@redhat.com>
Message-ID: <e214032c-0cb2-7d7c-13b3-e81b862b7bf4@oracle.com>

Thanks Roland.

Best regards,
Tobias

On 20.09.19 16:20, Roland Westrelin wrote:
> 
>> http://cr.openjdk.java.net/~thartmann/8231058/webrev.00/
> 
> Looks good to me.
> 
> Roland.
> 

From matthias.baesken at sap.com  Mon Sep 23 07:06:54 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 23 Sep 2019 07:06:54 +0000
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
 <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>
 <AM6PR02MB507864D0EB71CA0F9B6BE6CA93880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com>
Message-ID: <AM6PR02MB50789FD498534DF49E675B2893850@AM6PR02MB5078.eurprd02.prod.outlook.com>

Thanks for the review !
Alan, may I add you as reviewer too ?

Best regards, Matthias

> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Freitag, 20. September 2019 11:41
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-
> dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; core-libs-
> dev at openjdk.java.net
> Cc: Alan Bateman <Alan.Bateman at oracle.com>
> Subject: Re: [RFR] 8231171: remove remaining sun.java.launcher.pid
> references - was RE: sun.java.launcher.pid property usage
> 
> That looks fine to me.
> 
> Thanks,
> David
> 
> On 20/09/2019 7:14 pm, Baesken, Matthias wrote:
> > Hi David   , I adjusted the  test  (
> test/jdk/tools/launcher/TestSpecialArgs.java )   and removed the comments
> in os_bsd.cpp  (suggested by you) .
> > New webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8231171.1/
> >
> > Best regards, Matthias
> >
> >
> >
> >
> >> Hi Matthias,
> >>
> >> On 20/09/2019 5:03 pm, Baesken, Matthias wrote:
> >>>
> >>> Hello,  looks like   on Linux  there is a special check   in
> TestSpecialArgs.java
> >> for
> >>>
> >>>       launcherPidString = "launcher.pid="
> >>>
> >>> that  fails after   8231171  .
> >>> Should I adjust the test ?  Or  keep the  setting in the launcher on Linux ?
> >>
> >> IMHO adjust the test please.
> >>
> >> Thanks,
> >> David
> >> -----
> >>
> >

From david.holmes at oracle.com  Mon Sep 23 08:25:52 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Sep 2019 18:25:52 +1000
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
Message-ID: <6ee72118-4f3d-ac88-0dfd-7a000220e773@oracle.com>

Hi Tobias,

On 17/09/2019 12:19 am, Tobias Hartmann wrote:
> Hi,
> 
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8231058
> http://cr.openjdk.java.net/~thartmann/8231058/webrev.00/
> 
> I've accidentally broke CodeStrings::find_last with my patch for JDK-8224624 [1] but didn't notice
> because the failure only triggers with -XX:+VerifyOops and apparently we don't have any tests that
> execute with that flag.
> 
> The problem is that CodeString::offset() should only be called for comments. I've modified the
> condition accordingly. I've verified that the behavior is now equivalent to before JDK-8224624.

Functional change looks good. Thanks for explaining the history to me. :)

In the test do we generally use -XX:+IgnoreUnrecognizedVMOptions with 
develop flags or should we @require a debug vm?

David

> Thanks,
> Tobias
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8224624
> http://cr.openjdk.java.net/~thartmann/8224624/webrev.00/src/hotspot/share/asm/codeBuffer.cpp.sdiff.html
> 

From tobias.hartmann at oracle.com  Mon Sep 23 08:42:02 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 23 Sep 2019 10:42:02 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <6ee72118-4f3d-ac88-0dfd-7a000220e773@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
 <6ee72118-4f3d-ac88-0dfd-7a000220e773@oracle.com>
Message-ID: <99b2ec2b-ebf4-ebf4-ee5e-424753d9453e@oracle.com>

Hi David,

On 23.09.19 10:25, David Holmes wrote:
> Functional change looks good. Thanks for explaining the history to me. :)

Thanks for the review!

> In the test do we generally use -XX:+IgnoreUnrecognizedVMOptions with develop flags or should we
> @require a debug vm?

I've seen both but adding @requires is better in this case because the test is completely useless
when executed with a product VM. Updated webrev:
http://cr.openjdk.java.net/~thartmann/8231058/webrev.01/

Thanks,
Tobias

From david.holmes at oracle.com  Mon Sep 23 12:23:15 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 23 Sep 2019 22:23:15 +1000
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <99b2ec2b-ebf4-ebf4-ee5e-424753d9453e@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
 <6ee72118-4f3d-ac88-0dfd-7a000220e773@oracle.com>
 <99b2ec2b-ebf4-ebf4-ee5e-424753d9453e@oracle.com>
Message-ID: <afcfc2f3-c6dc-e94c-da8a-5dcd4413142f@oracle.com>

Looks good!

Thanks,
David
-----

On 23/09/2019 6:42 pm, Tobias Hartmann wrote:
> Hi David,
> 
> On 23.09.19 10:25, David Holmes wrote:
>> Functional change looks good. Thanks for explaining the history to me. :)
> 
> Thanks for the review!
> 
>> In the test do we generally use -XX:+IgnoreUnrecognizedVMOptions with develop flags or should we
>> @require a debug vm?
> 
> I've seen both but adding @requires is better in this case because the test is completely useless
> when executed with a product VM. Updated webrev:
> http://cr.openjdk.java.net/~thartmann/8231058/webrev.01/
> 
> Thanks,
> Tobias
> 

From tobias.hartmann at oracle.com  Mon Sep 23 12:30:53 2019
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 23 Sep 2019 14:30:53 +0200
Subject: [14] RFR(XS): 8231058: VerifyOops crashes with assert(_offset >=
 0) failed: offset for non comment?
In-Reply-To: <afcfc2f3-c6dc-e94c-da8a-5dcd4413142f@oracle.com>
References: <7c294485-ce2a-8532-afa3-33db74ac0c51@oracle.com>
 <6ee72118-4f3d-ac88-0dfd-7a000220e773@oracle.com>
 <99b2ec2b-ebf4-ebf4-ee5e-424753d9453e@oracle.com>
 <afcfc2f3-c6dc-e94c-da8a-5dcd4413142f@oracle.com>
Message-ID: <6e245c85-8cc0-c053-a164-39f22c403479@oracle.com>

Thanks David! Pushed.

Best regards,
Tobias

On 23.09.19 14:23, David Holmes wrote:
> Looks good!
> 
> Thanks,
> David
> -----
> 
> On 23/09/2019 6:42 pm, Tobias Hartmann wrote:
>> Hi David,
>>
>> On 23.09.19 10:25, David Holmes wrote:
>>> Functional change looks good. Thanks for explaining the history to me. :)
>>
>> Thanks for the review!
>>
>>> In the test do we generally use -XX:+IgnoreUnrecognizedVMOptions with develop flags or should we
>>> @require a debug vm?
>>
>> I've seen both but adding @requires is better in this case because the test is completely useless
>> when executed with a product VM. Updated webrev:
>> http://cr.openjdk.java.net/~thartmann/8231058/webrev.01/
>>
>> Thanks,
>> Tobias
>>

From Alan.Bateman at oracle.com  Mon Sep 23 13:56:08 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Sep 2019 14:56:08 +0100
Subject: [RFR] 8231171: remove remaining sun.java.launcher.pid references
 - was RE: sun.java.launcher.pid property usage
In-Reply-To: <AM6PR02MB50789FD498534DF49E675B2893850@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078259B511857872B64761293890@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <3db7390f-36df-d304-3188-d11e35a673ab@oracle.com>
 <AM6PR02MB50787814A010909771D93C5993880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <765279b9-1b60-88ad-8548-3f5cf1b19f28@oracle.com>
 <AM6PR02MB507864D0EB71CA0F9B6BE6CA93880@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <173137cf-2fbd-1d5a-17d2-a2d42265f688@oracle.com>
 <AM6PR02MB50789FD498534DF49E675B2893850@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <89fe0bc2-41d0-0e4c-d6a7-101304a1c151@oracle.com>

On 23/09/2019 08:06, Baesken, Matthias wrote:
> Thanks for the review !
> Alan, may I add you as reviewer too ?
>
Yes, okay with me too.

-Alan

From matthias.baesken at sap.com  Mon Sep 23 14:23:11 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 23 Sep 2019 14:23:11 +0000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
Message-ID: <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi David /  Mikhailo , I was busy with other tasks  but today  got back to  8229370 .

I noticed that in the meantime,   the test was excluded  with 

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

"Problemlist JFR TestNetworkUtilization test"


Do you think we still should  rely  on the OS counters , and expect to get  2+ network interfaces,  or  keep  the test excluded (or just relax  the check and  check for 1+  network interfaces on Linux)  ?


Best regards, Matthias



> 
> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
> > Hi David ,   I could  add some  optional  UL logging  to see   what happens.
> 
> I just want to see more visibility at the test level to ensure it is
> finding the interfaces and addresses I would expect it to find.
> 
> David
> 
> > Maybe the  OS counters   that are fetched by   os_perf    are not that
> reliable on some  kernels .
> >
> >
> > Best regards, Matthias
> >


From shade at redhat.com  Mon Sep 23 19:35:19 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Sep 2019 21:35:19 +0200
Subject: RFR (XXS) 8231375: AArch64 build failure after JDK-8230505
Message-ID: <ddef75f7-743d-bcdc-bd10-6b6029d66efc@redhat.com>

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

Trivial fix, missing parenthesis:

diff -r 08a5148e7c4e src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
--- a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp       Mon Sep 23 14:49:04 2019 -0400
+++ b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp       Mon Sep 23 21:28:12 2019 +0200
@@ -729,5 +729,5 @@

   } else if (dest->is_double_cpu()) {
-    if (is_reference_type(src->type()) {
+    if (is_reference_type(src->type())) {
       // Surprising to me but we can see move of a long to t_object
       __ verify_oop(src->as_register());

Testing: aarch64 build

-- 
Thanks,
-Aleksey


From daniel.daugherty at oracle.com  Mon Sep 23 19:44:03 2019
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 23 Sep 2019 15:44:03 -0400
Subject: RFR (XXS) 8231375: AArch64 build failure after JDK-8230505
In-Reply-To: <ddef75f7-743d-bcdc-bd10-6b6029d66efc@redhat.com>
References: <ddef75f7-743d-bcdc-bd10-6b6029d66efc@redhat.com>
Message-ID: <b74f84a4-5cd5-a2b6-cffe-99aa0e76ffe6@oracle.com>

Thumbs up. I concur that this is a trivial fix.

Dan


On 9/23/19 3:35 PM, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8231375
>
> Trivial fix, missing parenthesis:
>
> diff -r 08a5148e7c4e src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
> --- a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp       Mon Sep 23 14:49:04 2019 -0400
> +++ b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp       Mon Sep 23 21:28:12 2019 +0200
> @@ -729,5 +729,5 @@
>
>     } else if (dest->is_double_cpu()) {
> -    if (is_reference_type(src->type()) {
> +    if (is_reference_type(src->type())) {
>         // Surprising to me but we can see move of a long to t_object
>         __ verify_oop(src->as_register());
>
> Testing: aarch64 build
>


From shade at redhat.com  Mon Sep 23 19:47:33 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Sep 2019 21:47:33 +0200
Subject: RFR (XXS) 8231375: AArch64 build failure after JDK-8230505
In-Reply-To: <b74f84a4-5cd5-a2b6-cffe-99aa0e76ffe6@oracle.com>
References: <ddef75f7-743d-bcdc-bd10-6b6029d66efc@redhat.com>
 <b74f84a4-5cd5-a2b6-cffe-99aa0e76ffe6@oracle.com>
Message-ID: <a436c06c-a368-abc6-79d1-46fc2b84ba7a@redhat.com>

Thanks, pushed.

-Aleksey

On 9/23/19 9:44 PM, Daniel D. Daugherty wrote:
> Thumbs up. I concur that this is a trivial fix.
> 
> Dan
> 
> 
> On 9/23/19 3:35 PM, Aleksey Shipilev wrote:
>> Bug:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8231375
>>
>> Trivial fix, missing parenthesis:
>>
>> diff -r 08a5148e7c4e src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
>> --- a/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp?????? Mon Sep 23 14:49:04 2019 -0400
>> +++ b/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp?????? Mon Sep 23 21:28:12 2019 +0200
>> @@ -729,5 +729,5 @@
>>
>> ??? } else if (dest->is_double_cpu()) {
>> -??? if (is_reference_type(src->type()) {
>> +??? if (is_reference_type(src->type())) {
>> ??????? // Surprising to me but we can see move of a long to t_object
>> ??????? __ verify_oop(src->as_register());
>>
>> Testing: aarch64 build


From david.holmes at oracle.com  Mon Sep 23 23:10:56 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Sep 2019 09:10:56 +1000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
 <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>

Hi Matthias,

On 24/09/2019 12:23 am, Baesken, Matthias wrote:
> Hi David /  Mikhailo , I was busy with other tasks  but today  got back to  8229370 .
> 
> I noticed that in the meantime,   the test was excluded  with
> 
> https://bugs.openjdk.java.net/browse/JDK-8230115
> 
> "Problemlist JFR TestNetworkUtilization test"
> 
> 
> Do you think we still should  rely  on the OS counters , and expect to get  2+ network interfaces,  or  keep  the test excluded (or just relax  the check and  check for 1+  network interfaces on Linux)  ?

Exclusion is just a temporary measure to clean up the testing results, 
so this still needs to be fixed. I have nothing further to add from my 
comments in the bug:

 > So it should be as simple as changing 10.0.0.0:12345 into something
 > guaranteed to work?
 >
 > I think this needs to be looked at by the JFR folk and net-dev folk to
 > come up with a valid testing scenario.

It's not the number of interfaces that is the issue, it is generating 
traffic on the real interface.

Thanks,
David

> 
> Best regards, Matthias
> 
> 
> 
>>
>> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
>>> Hi David ,   I could  add some  optional  UL logging  to see   what happens.
>>
>> I just want to see more visibility at the test level to ensure it is
>> finding the interfaces and addresses I would expect it to find.
>>
>> David
>>
>>> Maybe the  OS counters   that are fetched by   os_perf    are not that
>> reliable on some  kernels .
>>>
>>>
>>> Best regards, Matthias
>>>
> 

From christoph.langer at sap.com  Tue Sep 24 13:59:27 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Sep 2019 13:59:27 +0000
Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible
Message-ID: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi,

please help reviewing the backport of test fix 8227642: [TESTBUG] Make docker tests podman compatible.

Bug: https://bugs.openjdk.java.net/browse/JDK-8227642
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/

Applying the patch rejected the hunk in  test/lib/jdk/test/lib/Platform.java. I, however, only had to place it correctly in the jdk11u-dev version of the file. The patch is prerequisite to backporting "8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage" which we regularly see failing in our 11u regression testing.

Thanks
Christoph


From sgehwolf at redhat.com  Tue Sep 24 14:12:27 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 24 Sep 2019 16:12:27 +0200
Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible
In-Reply-To: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com>

Hi Christoph,

On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote:
> Hi,
> 
> please help reviewing the backport of test fix 8227642: [TESTBUG]
> Make docker tests podman compatible.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227642
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9
> Webrev: 
> http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/

Looks good.

Please also backport JDK-8228434[1] as otherwise we risk breaking the
jdk/net/Sockets/Test.java test.

Thanks,
Severin

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


From christoph.langer at sap.com  Tue Sep 24 14:37:28 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Sep 2019 14:37:28 +0000
Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible
In-Reply-To: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com>
References: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com>
Message-ID: <AM6PR02MB5192095E8B16251F22C941FE8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Severin,

thanks for review and this hint. I've just created a backport patch and will run it through our nightlies. Will probably send out an RFR tomorrow.

Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java with 8227642 applied. But in any case, adding 8228434 will be better.

Best regards
Christoph

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Dienstag, 24. September 2019 16:12
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: hotspot-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman
> compatible
> 
> Hi Christoph,
> 
> On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote:
> > Hi,
> >
> > please help reviewing the backport of test fix 8227642: [TESTBUG]
> > Make docker tests podman compatible.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642
> > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9
> > Webrev:
> > http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/
> 
> Looks good.
> 
> Please also backport JDK-8228434[1] as otherwise we risk breaking the
> jdk/net/Sockets/Test.java test.
> 
> Thanks,
> Severin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8228434


From sgehwolf at redhat.com  Tue Sep 24 15:00:15 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 24 Sep 2019 17:00:15 +0200
Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible
In-Reply-To: <AM6PR02MB5192095E8B16251F22C941FE8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com>
 <AM6PR02MB5192095E8B16251F22C941FE8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com>

Hi Christoph,

On Tue, 2019-09-24 at 14:37 +0000, Langer, Christoph wrote:
> Hi Severin,
> 
> thanks for review and this hint. I've just created a backport patch
> and will run it through our nightlies. Will probably send out an RFR
> tomorrow.
> 
> Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java
> with 8227642 applied. But in any case, adding 8228434 will be better.

On second thought, it looks like the OpenJDK 11u version of
jdk/net/Sockets/Test.java doesn't use Platform (jdk/jdk's version
does). So we are probably good at this point. No need for 8228434 in
JDK 11u, AFAICS. Usages of Platform + running with a SecurityManager
triggers the problem. OpenJDK 11 seems OK.

Thanks,
Severin

> 
> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com>
> > Sent: Dienstag, 24. September 2019 16:12
> > To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Cc: hotspot-dev at openjdk.java.net
> > Subject: Re: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman
> > compatible
> > 
> > Hi Christoph,
> > 
> > On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote:
> > > Hi,
> > > 
> > > please help reviewing the backport of test fix 8227642: [TESTBUG]
> > > Make docker tests podman compatible.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642
> > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9
> > > Webrev:
> > > http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/
> > 
> > Looks good.
> > 
> > Please also backport JDK-8228434[1] as otherwise we risk breaking the
> > jdk/net/Sockets/Test.java test.
> > 
> > Thanks,
> > Severin
> > 
> > [1] https://bugs.openjdk.java.net/browse/JDK-8228434


From aph at redhat.com  Tue Sep 24 18:03:46 2019
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Sep 2019 19:03:46 +0100
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
 <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
Message-ID: <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>

On 9/22/19 9:19 AM, John Paul Adrian Glaubitz wrote:
> On 9/7/19 12:44 AM, John Paul Adrian Glaubitz wrote:
>> In addition to the build failure of the server VM with gcc-9, Zero is affected as
>> well, but here it's not a syntax issue but the VM is segfaulting when built with
>> gcc-9.
>>
>> Backtrace is below. Any suggestions?
> Reported to gcc upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855.

It's not obviously a GCC bug.

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

From glaubitz at physik.fu-berlin.de  Tue Sep 24 21:29:01 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 24 Sep 2019 23:29:01 +0200
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
 <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
 <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>
Message-ID: <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>

On 9/24/19 8:03 PM, Andrew Haley wrote:
> On 9/22/19 9:19 AM, John Paul Adrian Glaubitz wrote:
>> On 9/7/19 12:44 AM, John Paul Adrian Glaubitz wrote:
>>> In addition to the build failure of the server VM with gcc-9, Zero is affected as
>>> well, but here it's not a syntax issue but the VM is segfaulting when built with
>>> gcc-9.
>>>
>>> Backtrace is below. Any suggestions?
>> Reported to gcc upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855.
> 
> It's not obviously a GCC bug.

Care to elaborate? What are the pointers in your opinion? It builds fine
with gcc-7 and it used to build fine with older snapshot versions of
gcc-8. I haven't tracked down yet which gcc patch introduced the
breakage.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From vitalyd at gmail.com  Tue Sep 24 21:36:10 2019
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 24 Sep 2019 17:36:10 -0400
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
 <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
 <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>
 <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>
Message-ID: <CAHjP37HMT81fne04JHHoru5sukNovgrS3rdgQ7wjzeyKzdu3TQ@mail.gmail.com>

It might help (on the gcc bugtracker issue, if nothing else) to show gcc-8
(or latest working version) disassembly of SharedRuntime::generate_stubs()
and see what, if anything, stands out vs gcc9.

Also, what -O level is breaking?

It may be some UB that a newer version of gcc picks up on, so not
necessarily their bug.

On Tue, Sep 24, 2019 at 5:29 PM John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> On 9/24/19 8:03 PM, Andrew Haley wrote:
> > On 9/22/19 9:19 AM, John Paul Adrian Glaubitz wrote:
> >> On 9/7/19 12:44 AM, John Paul Adrian Glaubitz wrote:
> >>> In addition to the build failure of the server VM with gcc-9, Zero is
> affected as
> >>> well, but here it's not a syntax issue but the VM is segfaulting when
> built with
> >>> gcc-9.
> >>>
> >>> Backtrace is below. Any suggestions?
> >> Reported to gcc upstream as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855.
> >
> > It's not obviously a GCC bug.
>
> Care to elaborate? What are the pointers in your opinion? It builds fine
> with gcc-7 and it used to build fine with older snapshot versions of
> gcc-8. I haven't tracked down yet which gcc patch introduced the
> breakage.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
-- 
Sent from my phone

From matthias.baesken at sap.com  Wed Sep 25 13:08:01 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 25 Sep 2019 13:08:01 +0000
Subject: RFR : 8231448:  s390 and ppc - replace JVM type comparisons to
 T_OBJECT and T_ARRAY with call to is_reference_type
Message-ID: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello, please review the following change .

Recently,  https://bugs.openjdk.java.net/browse/JDK-8230505

  replaced  a lot of  JVM conditionals compares against T_OBJECT and T_ARRAY   ( for readability and future extendability )  with a call to

is_reference_type .

However   the change  8230505    did not  change  the calls  in src/hotspot/cpu/ppc   and  src/hotspot/cpu/s390  .
My change  adjusts the remaining calls  in the  ppc / s390  coding .



Bug/webrev :

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

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


Thanks, Matthias

From christoph.langer at sap.com  Wed Sep 25 14:18:42 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 25 Sep 2019 14:18:42 +0000
Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible
In-Reply-To: <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com>
References: <AM6PR02MB5192F8CEAC864033237AE66E8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com>
 <AM6PR02MB5192095E8B16251F22C941FE8A840@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com>
Message-ID: <AM6PR02MB5192CDC58CAC971809F5FA038A870@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Severin,

> > Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java
> > with 8227642 applied. But in any case, adding 8228434 will be better.
> 
> On second thought, it looks like the OpenJDK 11u version of
> jdk/net/Sockets/Test.java doesn't use Platform (jdk/jdk's version
> does). So we are probably good at this point. No need for 8228434 in
> JDK 11u, AFAICS. Usages of Platform + running with a SecurityManager
> triggers the problem. OpenJDK 11 seems OK.

OK, that explains it. However, I think it's beneficial to take JDK-8228434 together with JDK-8227642. I ran a backport of it through our nightlies and the results still look good. Will send out an RFR shortly.

Best regards
Christoph


From coleen.phillimore at oracle.com  Wed Sep 25 14:33:14 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 10:33:14 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
Message-ID: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>

Summary: Dont create nmethod if classes have been redefined since 
compilation start.

The bug was caused by a new nmethod created with an old Method in the 
metadata section.? Added verification (which hit on windows) and NSV in 
the other place where the method can be replaced in the nmethod metadata 
section.

There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
needed also in the graal compiler.

Tested with tier1-6 and failing test 100 times.

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

Thanks,
Coleen

From coleen.phillimore at oracle.com  Wed Sep 25 15:18:13 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 11:18:13 -0400
Subject: RFR : 8231448: s390 and ppc - replace JVM type comparisons to
 T_OBJECT and T_ARRAY with call to is_reference_type
In-Reply-To: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <12141b1b-0a6b-c06e-b021-d90f8f76f3e6@oracle.com>

http://cr.openjdk.java.net/~mbaesken/webrevs/8231448.0/src/hotspot/cpu/ppc/gc/shared/modRefBarrierSetAssembler_ppc.hpp.udiff.html

This seems to just have the copyright change but no other.

Otherwise, looks good.? There were a lot of these!? Thank you for fixing 
this.

Coleen


On 9/25/19 9:08 AM, Baesken, Matthias wrote:
> Hello, please review the following change .
>
> Recently,  https://bugs.openjdk.java.net/browse/JDK-8230505
>
>    replaced  a lot of  JVM conditionals compares against T_OBJECT and T_ARRAY   ( for readability and future extendability )  with a call to
>
> is_reference_type .
>
> However   the change  8230505    did not  change  the calls  in src/hotspot/cpu/ppc   and  src/hotspot/cpu/s390  .
> My change  adjusts the remaining calls  in the  ppc / s390  coding .
>
>
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8231448
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231448.0/
>
>
> Thanks, Matthias


From gilles.m.duboscq at oracle.com  Wed Sep 25 15:26:24 2019
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Wed, 25 Sep 2019 17:26:24 +0200
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
Message-ID: <4a6b74ab-f235-fb15-50b6-9bf1acee67d9@oracle.com>

It looks to me like `_jvmti_redefinition_count` only needs to be checked for consistency during code installation (which you do in jvmciEnv & ciEnv).
The compiler doesn't need to look at the value during the compilation process so I don't think we need it in `vmStructs_jvmci.cpp`.

  Gilles

On 25/09/2019 16:33, coleen.phillimore at oracle.com wrote:
> Summary: Dont create nmethod if classes have been redefined since compilation start.
> 
> The bug was caused by a new nmethod created with an old Method in the metadata section.? Added verification (which hit on windows) and NSV in the other place where the method can be replaced in the nmethod metadata section.
> 
> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be needed also in the graal compiler.
> 
> Tested with tier1-6 and failing test 100 times.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
> 
> Thanks,
> Coleen

From lois.foltan at oracle.com  Wed Sep 25 16:28:13 2019
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 25 Sep 2019 12:28:13 -0400
Subject: RFR : 8231448: s390 and ppc - replace JVM type comparisons to
 T_OBJECT and T_ARRAY with call to is_reference_type
In-Reply-To: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <c7bb7f11-bf11-63f7-ce4e-e5ff5e6d26fb@oracle.com>

On 9/25/2019 9:08 AM, Baesken, Matthias wrote:
>
> Hello, please review the following change .
>
> Recently, https://bugs.openjdk.java.net/browse/JDK-8230505
>
> ? replaced? a lot of ?JVM conditionals compares against T_OBJECT and 
> T_ARRAY? ?( for readability and future extendability )? with a call to
>
> is_reference_type .
>
> However?? the change 8230505? ??did not? change? the calls? in 
> src/hotspot/cpu/ppc?? and? src/hotspot/cpu/s390? .
>
> My change? adjusts the remaining calls? in the? ppc / s390? coding .
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8231448
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231448.0/
>

Looks good.? Thank you for making these changes.? One minor comment:

src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
- line #1298 there is a space in the assert conditional between "!" and 
"is_reference_type"

I don't need to see another webrev for this.

Thanks,
Lois

> Thanks, Matthias
>


From aph at redhat.com  Wed Sep 25 17:28:10 2019
From: aph at redhat.com (Andrew Haley)
Date: Wed, 25 Sep 2019 18:28:10 +0100
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
 <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
 <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>
 <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>
Message-ID: <36362b68-cfce-e159-8fa7-26549263d6db@redhat.com>

On 9/24/19 10:29 PM, John Paul Adrian Glaubitz wrote:
> On 9/24/19 8:03 PM, Andrew Haley wrote:
>> On 9/22/19 9:19 AM, John Paul Adrian Glaubitz wrote:
>>> On 9/7/19 12:44 AM, John Paul Adrian Glaubitz wrote:
>>>> In addition to the build failure of the server VM with gcc-9, Zero is affected as
>>>> well, but here it's not a syntax issue but the VM is segfaulting when built with
>>>> gcc-9.
>>>>
>>>> Backtrace is below. Any suggestions?
>>> Reported to gcc upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855.
>>
>> It's not obviously a GCC bug.
> 
> Care to elaborate? What are the pointers in your opinion? It builds fine
> with gcc-7 and it used to build fine with older snapshot versions of
> gcc-8. I haven't tracked down yet which gcc patch introduced the
> breakage.

It could be a bug in the JVM. I have recently debugged problems which
were due to undefined behaviour in HotSpot. It wouldn't be a terrible
idea to run with GCC's UB Sanitizer and fix a few of the bugs.

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

From coleen.phillimore at oracle.com  Wed Sep 25 19:53:05 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 15:53:05 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <4a6b74ab-f235-fb15-50b6-9bf1acee67d9@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <4a6b74ab-f235-fb15-50b6-9bf1acee67d9@oracle.com>
Message-ID: <4cfb7468-a19c-8741-f476-a72325a5d967@oracle.com>

Thanks Gilles, I'll remove it from vmStructs_jvmci.cpp. So the jvmci 
code looks good?
thanks,
Coleen

On 9/25/19 11:26 AM, Gilles Duboscq wrote:
> It looks to me like `_jvmti_redefinition_count` only needs to be 
> checked for consistency during code installation (which you do in 
> jvmciEnv & ciEnv).
> The compiler doesn't need to look at the value during the compilation 
> process so I don't think we need it in `vmStructs_jvmci.cpp`.
>
> ?Gilles
>
> On 25/09/2019 16:33, coleen.phillimore at oracle.com wrote:
>> Summary: Dont create nmethod if classes have been redefined since 
>> compilation start.
>>
>> The bug was caused by a new nmethod created with an old Method in the 
>> metadata section.? Added verification (which hit on windows) and NSV 
>> in the other place where the method can be replaced in the nmethod 
>> metadata section.
>>
>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>> needed also in the graal compiler.
>>
>> Tested with tier1-6 and failing test 100 times.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>
>> Thanks,
>> Coleen


From coleen.phillimore at oracle.com  Wed Sep 25 21:22:16 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 17:22:16 -0400
Subject: RFR (S) 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine
 fails due a) MT-unsafe modification of inline cache
Message-ID: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>

Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted

This is the comment in the bug that describes this race and this fix:
https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441

The rest of the bug and sightings are actually caused by 
https://bugs.openjdk.java.net/browse/JDK-8226690,
and this one might have been caused by it also, but the race that Erik 
describes is possible as well.

The s390 code had an exception for callee->is_compiled_lambda_form() 
which should probably apply to all the platforms, so the code is the 
same on all the platforms with this change.

Tested with tier1-6.

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

Thanks,
Coleen

From coleen.phillimore at oracle.com  Wed Sep 25 21:28:15 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 17:28:15 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
Message-ID: <19865f51-596b-5782-a763-5dfda29a65e8@oracle.com>

Adding serviceability-dev.
Coleen

On 9/25/19 5:22 PM, coleen.phillimore at oracle.com wrote:
> Summary: allow old methods in 
> CompiledStaticDirectCall::set_to_interpreted
>
> This is the comment in the bug that describes this race and this fix:
> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>
>
> The rest of the bug and sightings are actually caused by 
> https://bugs.openjdk.java.net/browse/JDK-8226690,
> and this one might have been caused by it also, but the race that Erik 
> describes is possible as well.
>
> The s390 code had an exception for callee->is_compiled_lambda_form() 
> which should probably apply to all the platforms, so the code is the 
> same on all the platforms with this change.
>
> Tested with tier1-6.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Wed Sep 25 21:29:07 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 17:29:07 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
Message-ID: <d3ca60c6-0d21-44a0-2416-aaf2dc12f07a@oracle.com>

Adding serviceability-dev.
Coleen

On 9/25/19 10:33 AM, coleen.phillimore at oracle.com wrote:
> Summary: Dont create nmethod if classes have been redefined since 
> compilation start.
>
> The bug was caused by a new nmethod created with an old Method in the 
> metadata section.? Added verification (which hit on windows) and NSV 
> in the other place where the method can be replaced in the nmethod 
> metadata section.
>
> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
> needed also in the graal compiler.
>
> Tested with tier1-6 and failing test 100 times.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>
> Thanks,
> Coleen


From serguei.spitsyn at oracle.com  Wed Sep 25 21:56:04 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 25 Sep 2019 14:56:04 -0700
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <19865f51-596b-5782-a763-5dfda29a65e8@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <19865f51-596b-5782-a763-5dfda29a65e8@oracle.com>
Message-ID: <6db3af24-251b-283b-3278-a1dd5b9a6326@oracle.com>

Hi Coleen,

This looks fine to me.
Nice unification for all platforms.
Thank you for taking care about this issue!

Thanks,
Serguei


On 9/25/19 2:28 PM, coleen.phillimore at oracle.com wrote:
> Adding serviceability-dev.
> Coleen
>
> On 9/25/19 5:22 PM, coleen.phillimore at oracle.com wrote:
>> Summary: allow old methods in 
>> CompiledStaticDirectCall::set_to_interpreted
>>
>> This is the comment in the bug that describes this race and this fix:
>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>
>>
>> The rest of the bug and sightings are actually caused by 
>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>> and this one might have been caused by it also, but the race that 
>> Erik describes is possible as well.
>>
>> The s390 code had an exception for callee->is_compiled_lambda_form() 
>> which should probably apply to all the platforms, so the code is the 
>> same on all the platforms with this change.
>>
>> Tested with tier1-6.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>
>> Thanks,
>> Coleen
>


From dean.long at oracle.com  Wed Sep 25 22:18:46 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 25 Sep 2019 15:18:46 -0700
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
Message-ID: <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>

Saving and restoring redefinition_count for compiler replay doesn't make 
sense to me.? It won't affect the generated code, and we probably 
shouldn't even be installing/registering replay nmethods. I would remove 
the ciEnv::dump_replay_data_unsafe() and process_JvmtiExport() changes.

dl

On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
> Summary: Dont create nmethod if classes have been redefined since 
> compilation start.
>
> The bug was caused by a new nmethod created with an old Method in the 
> metadata section.? Added verification (which hit on windows) and NSV 
> in the other place where the method can be replaced in the nmethod 
> metadata section.
>
> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
> needed also in the graal compiler.
>
> Tested with tier1-6 and failing test 100 times.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>
> Thanks,
> Coleen


From serguei.spitsyn at oracle.com  Thu Sep 26 00:54:12 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 25 Sep 2019 17:54:12 -0700
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <d3ca60c6-0d21-44a0-2416-aaf2dc12f07a@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <d3ca60c6-0d21-44a0-2416-aaf2dc12f07a@oracle.com>
Message-ID: <842f7b3c-f9a1-9acf-320d-9c1383554b92@oracle.com>

Hi Coleen,

It looks pretty good to me.
I'm not aware much about reply.

Thanks,
Serguei


On 9/25/19 2:29 PM, coleen.phillimore at oracle.com wrote:
> Adding serviceability-dev.
> Coleen
>
> On 9/25/19 10:33 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Dont create nmethod if classes have been redefined since 
>> compilation start.
>>
>> The bug was caused by a new nmethod created with an old Method in the 
>> metadata section.? Added verification (which hit on windows) and NSV 
>> in the other place where the method can be replaced in the nmethod 
>> metadata section.
>>
>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>> needed also in the graal compiler.
>>
>> Tested with tier1-6 and failing test 100 times.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>
>> Thanks,
>> Coleen
>


From coleen.phillimore at oracle.com  Thu Sep 26 01:21:20 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 21:21:20 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
Message-ID: <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>


I see.? I dumped the redefinition count in the replay data because I saw 
the other fields were dumped there.? Would they also not affect the 
generated code?

I can remove these changes.

Thanks,
Coleen

On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
> Saving and restoring redefinition_count for compiler replay doesn't 
> make sense to me.? It won't affect the generated code, and we probably 
> shouldn't even be installing/registering replay nmethods. I would 
> remove the ciEnv::dump_replay_data_unsafe() and process_JvmtiExport() 
> changes.
>
> dl
>
> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Dont create nmethod if classes have been redefined since 
>> compilation start.
>>
>> The bug was caused by a new nmethod created with an old Method in the 
>> metadata section.? Added verification (which hit on windows) and NSV 
>> in the other place where the method can be replaced in the nmethod 
>> metadata section.
>>
>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>> needed also in the graal compiler.
>>
>> Tested with tier1-6 and failing test 100 times.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>
>> Thanks,
>> Coleen
>


From coleen.phillimore at oracle.com  Thu Sep 26 01:23:39 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 21:23:39 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <842f7b3c-f9a1-9acf-320d-9c1383554b92@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <d3ca60c6-0d21-44a0-2416-aaf2dc12f07a@oracle.com>
 <842f7b3c-f9a1-9acf-320d-9c1383554b92@oracle.com>
Message-ID: <34860f1a-41a1-82a8-0fa0-904c5cec196d@oracle.com>


Thanks Serguei!? I removed the replay code.
Coleen

On 9/25/19 8:54 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> It looks pretty good to me.
> I'm not aware much about reply.
>
> Thanks,
> Serguei
>
>
> On 9/25/19 2:29 PM, coleen.phillimore at oracle.com wrote:
>> Adding serviceability-dev.
>> Coleen
>>
>> On 9/25/19 10:33 AM, coleen.phillimore at oracle.com wrote:
>>> Summary: Dont create nmethod if classes have been redefined since 
>>> compilation start.
>>>
>>> The bug was caused by a new nmethod created with an old Method in 
>>> the metadata section.? Added verification (which hit on windows) and 
>>> NSV in the other place where the method can be replaced in the 
>>> nmethod metadata section.
>>>
>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>> needed also in the graal compiler.
>>>
>>> Tested with tier1-6 and failing test 100 times.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>
>>> Thanks,
>>> Coleen
>>
>


From coleen.phillimore at oracle.com  Thu Sep 26 01:24:19 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 21:24:19 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <6db3af24-251b-283b-3278-a1dd5b9a6326@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <19865f51-596b-5782-a763-5dfda29a65e8@oracle.com>
 <6db3af24-251b-283b-3278-a1dd5b9a6326@oracle.com>
Message-ID: <56a45e1a-852f-2fa0-d67e-17645d44a49b@oracle.com>


Thanks Serguei!
Coleen

On 9/25/19 5:56 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> This looks fine to me.
> Nice unification for all platforms.
> Thank you for taking care about this issue!
>
> Thanks,
> Serguei
>
>
> On 9/25/19 2:28 PM, coleen.phillimore at oracle.com wrote:
>> Adding serviceability-dev.
>> Coleen
>>
>> On 9/25/19 5:22 PM, coleen.phillimore at oracle.com wrote:
>>> Summary: allow old methods in 
>>> CompiledStaticDirectCall::set_to_interpreted
>>>
>>> This is the comment in the bug that describes this race and this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>
>>>
>>> The rest of the bug and sightings are actually caused by 
>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>> and this one might have been caused by it also, but the race that 
>>> Erik describes is possible as well.
>>>
>>> The s390 code had an exception for callee->is_compiled_lambda_form() 
>>> which should probably apply to all the platforms, so the code is the 
>>> same on all the platforms with this change.
>>>
>>> Tested with tier1-6.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>
>>> Thanks,
>>> Coleen
>>
>


From coleen.phillimore at oracle.com  Thu Sep 26 01:29:32 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Wed, 25 Sep 2019 21:29:32 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
Message-ID: <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>



On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>
> I see.? I dumped the redefinition count in the replay data because I 
> saw the other fields were dumped there.? Would they also not affect 
> the generated code?
>
> I can remove these changes.

open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev

Rebuilt and retested with the ciReplay tests.? Thank you for looking at 
the change.
Coleen
>
> Thanks,
> Coleen
>
> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>> Saving and restoring redefinition_count for compiler replay doesn't 
>> make sense to me.? It won't affect the generated code, and we 
>> probably shouldn't even be installing/registering replay nmethods. I 
>> would remove the ciEnv::dump_replay_data_unsafe() and 
>> process_JvmtiExport() changes.
>>
>> dl
>>
>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>> Summary: Dont create nmethod if classes have been redefined since 
>>> compilation start.
>>>
>>> The bug was caused by a new nmethod created with an old Method in 
>>> the metadata section.? Added verification (which hit on windows) and 
>>> NSV in the other place where the method can be replaced in the 
>>> nmethod metadata section.
>>>
>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>> needed also in the graal compiler.
>>>
>>> Tested with tier1-6 and failing test 100 times.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>
>>> Thanks,
>>> Coleen
>>
>


From dean.long at oracle.com  Thu Sep 26 04:01:35 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 25 Sep 2019 21:01:35 -0700
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
Message-ID: <b77122d9-e2ac-99f4-593a-1692e7f4079e@oracle.com>

On 9/25/19 6:21 PM, coleen.phillimore at oracle.com wrote:
>
> I see.? I dumped the redefinition count in the replay data because I 
> saw the other fields were dumped there.? Would they also not affect 
> the generated code?
>

I know some like _jvmti_can_access_local_variables can affect the 
generated code.? See

https://github.com/openjdk/jdk/blob/c83c8515ebb4e49fb63c9b896581c9f056268aa0/src/hotspot/share/ci/ciEnv.hpp#L344

dl
> I can remove these changes.
>
> Thanks,
> Coleen
>
> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>> Saving and restoring redefinition_count for compiler replay doesn't 
>> make sense to me.? It won't affect the generated code, and we 
>> probably shouldn't even be installing/registering replay nmethods. I 
>> would remove the ciEnv::dump_replay_data_unsafe() and 
>> process_JvmtiExport() changes.
>>
>> dl
>>
>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>> Summary: Dont create nmethod if classes have been redefined since 
>>> compilation start.
>>>
>>> The bug was caused by a new nmethod created with an old Method in 
>>> the metadata section.? Added verification (which hit on windows) and 
>>> NSV in the other place where the method can be replaced in the 
>>> nmethod metadata section.
>>>
>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>> needed also in the graal compiler.
>>>
>>> Tested with tier1-6 and failing test 100 times.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>
>>> Thanks,
>>> Coleen
>>
>


From dean.long at oracle.com  Thu Sep 26 04:02:25 2019
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Wed, 25 Sep 2019 21:02:25 -0700
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
Message-ID: <b5248303-43d1-c38b-6808-e86aa15d849b@oracle.com>

Looks good.

dl

On 9/25/19 6:29 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> I see.? I dumped the redefinition count in the replay data because I 
>> saw the other fields were dumped there.? Would they also not affect 
>> the generated code?
>>
>> I can remove these changes.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>
> Rebuilt and retested with the ciReplay tests.? Thank you for looking 
> at the change.
> Coleen
>>
>> Thanks,
>> Coleen
>>
>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>> make sense to me.? It won't affect the generated code, and we 
>>> probably shouldn't even be installing/registering replay nmethods. I 
>>> would remove the ciEnv::dump_replay_data_unsafe() and 
>>> process_JvmtiExport() changes.
>>>
>>> dl
>>>
>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>> compilation start.
>>>>
>>>> The bug was caused by a new nmethod created with an old Method in 
>>>> the metadata section.? Added verification (which hit on windows) 
>>>> and NSV in the other place where the method can be replaced in the 
>>>> nmethod metadata section.
>>>>
>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>>> needed also in the graal compiler.
>>>>
>>>> Tested with tier1-6 and failing test 100 times.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>


From matthias.baesken at sap.com  Thu Sep 26 07:08:12 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 26 Sep 2019 07:08:12 +0000
Subject: RFR : 8231448: s390 and ppc - replace JVM type comparisons to
 T_OBJECT and T_ARRAY with call to is_reference_type
In-Reply-To: <c7bb7f11-bf11-63f7-ce4e-e5ff5e6d26fb@oracle.com>
References: <AM6PR02MB5078B93BD10127301DB1AF3F93870@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <c7bb7f11-bf11-63f7-ce4e-e5ff5e6d26fb@oracle.com>
Message-ID: <AM6PR02MB5078BCD18137685060B6183B93860@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hi   Lois, thanks  for the review .
May I  get a second review  for this  ?

Best regards, Matthias


From: Lois Foltan <lois.foltan at oracle.com>
Sent: Mittwoch, 25. September 2019 18:28
To: Baesken, Matthias <matthias.baesken at sap.com>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
Subject: Re: RFR : 8231448: s390 and ppc - replace JVM type comparisons to T_OBJECT and T_ARRAY with call to is_reference_type

On 9/25/2019 9:08 AM, Baesken, Matthias wrote:

Hello, please review the following change .

Recently,  https://bugs.openjdk.java.net/browse/JDK-8230505

  replaced  a lot of  JVM conditionals compares against T_OBJECT and T_ARRAY   ( for readability and future extendability )  with a call to

is_reference_type .

However   the change  8230505    did not  change  the calls  in src/hotspot/cpu/ppc   and  src/hotspot/cpu/s390  .
My change  adjusts the remaining calls  in the  ppc / s390  coding .



Bug/webrev :

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

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

Looks good.  Thank you for making these changes.  One minor comment:

src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
- line #1298 there is a space in the assert conditional between "!" and "is_reference_type"

I don't need to see another webrev for this.

Thanks,
Lois




Thanks, Matthias


From serguei.spitsyn at oracle.com  Thu Sep 26 08:47:05 2019
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 26 Sep 2019 01:47:05 -0700
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
Message-ID: <b7c86f0b-b5c7-d939-7730-8637a2052a88@oracle.com>

Hi Coleen,

The .02/webrev looks good.
You also removed changes in the src/hotspot/share/jvmci/vmStructs_jvmci.cpp.
Was it intentional?

Thanks,
Serguei


On 9/25/19 18:29, coleen.phillimore at oracle.com wrote:
>
>
> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> I see.? I dumped the redefinition count in the replay data because I 
>> saw the other fields were dumped there.? Would they also not affect 
>> the generated code?
>>
>> I can remove these changes.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>
> Rebuilt and retested with the ciReplay tests.? Thank you for looking 
> at the change.
> Coleen
>>
>> Thanks,
>> Coleen
>>
>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>> make sense to me.? It won't affect the generated code, and we 
>>> probably shouldn't even be installing/registering replay nmethods. I 
>>> would remove the ciEnv::dump_replay_data_unsafe() and 
>>> process_JvmtiExport() changes.
>>>
>>> dl
>>>
>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>> compilation start.
>>>>
>>>> The bug was caused by a new nmethod created with an old Method in 
>>>> the metadata section.? Added verification (which hit on windows) 
>>>> and NSV in the other place where the method can be replaced in the 
>>>> nmethod metadata section.
>>>>
>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>>> needed also in the graal compiler.
>>>>
>>>> Tested with tier1-6 and failing test 100 times.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>


From erik.osterlund at oracle.com  Thu Sep 26 09:43:43 2019
From: erik.osterlund at oracle.com (erik.osterlund at oracle.com)
Date: Thu, 26 Sep 2019 11:43:43 +0200
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
Message-ID: <bbf73fd4-9e3c-4731-64db-4efb02dfbb4b@oracle.com>

Hi Coleen,

Could you please make the counter uint64_t instead? We usually use 64 
bit unsigned counters when we don't want to think about overflow. 
Otherwise I like the approach. Don't need another webrev... This looks good.

Thanks,
/Erik

On 9/26/19 3:29 AM, coleen.phillimore at oracle.com wrote:
>
>
> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> I see.? I dumped the redefinition count in the replay data because I 
>> saw the other fields were dumped there.? Would they also not affect 
>> the generated code?
>>
>> I can remove these changes.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>
> Rebuilt and retested with the ciReplay tests.? Thank you for looking 
> at the change.
> Coleen
>>
>> Thanks,
>> Coleen
>>
>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>> make sense to me.? It won't affect the generated code, and we 
>>> probably shouldn't even be installing/registering replay nmethods. I 
>>> would remove the ciEnv::dump_replay_data_unsafe() and 
>>> process_JvmtiExport() changes.
>>>
>>> dl
>>>
>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>> compilation start.
>>>>
>>>> The bug was caused by a new nmethod created with an old Method in 
>>>> the metadata section.? Added verification (which hit on windows) 
>>>> and NSV in the other place where the method can be replaced in the 
>>>> nmethod metadata section.
>>>>
>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>>> needed also in the graal compiler.
>>>>
>>>> Tested with tier1-6 and failing test 100 times.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>

From erik.osterlund at oracle.com  Thu Sep 26 09:47:16 2019
From: erik.osterlund at oracle.com (erik.osterlund at oracle.com)
Date: Thu, 26 Sep 2019 11:47:16 +0200
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
Message-ID: <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>

Hi Coleen,

Looks good.

Thanks,
/Erik

On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
> Summary: allow old methods in 
> CompiledStaticDirectCall::set_to_interpreted
>
> This is the comment in the bug that describes this race and this fix:
> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>
>
> The rest of the bug and sightings are actually caused by 
> https://bugs.openjdk.java.net/browse/JDK-8226690,
> and this one might have been caused by it also, but the race that Erik 
> describes is possible as well.
>
> The s390 code had an exception for callee->is_compiled_lambda_form() 
> which should probably apply to all the platforms, so the code is the 
> same on all the platforms with this change.
>
> Tested with tier1-6.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>
> Thanks,
> Coleen

From gilles.m.duboscq at oracle.com  Thu Sep 26 09:53:12 2019
From: gilles.m.duboscq at oracle.com (Gilles Duboscq)
Date: Thu, 26 Sep 2019 11:53:12 +0200
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <4cfb7468-a19c-8741-f476-a72325a5d967@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <4a6b74ab-f235-fb15-50b6-9bf1acee67d9@oracle.com>
 <4cfb7468-a19c-8741-f476-a72325a5d967@oracle.com>
Message-ID: <1270661a-db22-894d-6208-65251afe8022@oracle.com>

The JVMCI changes look good.

Thank you,
  Gilles

On 25/09/2019 21:53, coleen.phillimore at oracle.com wrote:
> Thanks Gilles, I'll remove it from vmStructs_jvmci.cpp. So the jvmci code looks good?
> thanks,
> Coleen
> 
> On 9/25/19 11:26 AM, Gilles Duboscq wrote:
>> It looks to me like `_jvmti_redefinition_count` only needs to be checked for consistency during code installation (which you do in jvmciEnv & ciEnv).
>> The compiler doesn't need to look at the value during the compilation process so I don't think we need it in `vmStructs_jvmci.cpp`.
>>
>> ?Gilles
>>
>> On 25/09/2019 16:33, coleen.phillimore at oracle.com wrote:
>>> Summary: Dont create nmethod if classes have been redefined since compilation start.
>>>
>>> The bug was caused by a new nmethod created with an old Method in the metadata section.? Added verification (which hit on windows) and NSV in the other place where the method can be replaced in the nmethod metadata section.
>>>
>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be needed also in the graal compiler.
>>>
>>> Tested with tier1-6 and failing test 100 times.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>
>>> Thanks,
>>> Coleen
> 

From coleen.phillimore at oracle.com  Thu Sep 26 11:24:16 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 07:24:16 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
Message-ID: <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>

Thanks Erik!
Coleen

On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
> Hi Coleen,
>
> Looks good.
>
> Thanks,
> /Erik
>
> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>> Summary: allow old methods in 
>> CompiledStaticDirectCall::set_to_interpreted
>>
>> This is the comment in the bug that describes this race and this fix:
>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>
>>
>> The rest of the bug and sightings are actually caused by 
>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>> and this one might have been caused by it also, but the race that 
>> Erik describes is possible as well.
>>
>> The s390 code had an exception for callee->is_compiled_lambda_form() 
>> which should probably apply to all the platforms, so the code is the 
>> same on all the platforms with this change.
>>
>> Tested with tier1-6.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>
>> Thanks,
>> Coleen


From coleen.phillimore at oracle.com  Thu Sep 26 11:27:17 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 07:27:17 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <b7c86f0b-b5c7-d939-7730-8637a2052a88@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
 <b7c86f0b-b5c7-d939-7730-8637a2052a88@oracle.com>
Message-ID: <3d6ade0e-82bb-b645-a5ec-1b38bda2b907@oracle.com>



On 9/26/19 4:47 AM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
> The .02/webrev looks good.
> You also removed changes in the 
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp.
> Was it intentional?

Yes, Gilles said that graal doesn't need the field.

Thanks for reviewing.
Coleen
>
> Thanks,
> Serguei
>
>
> On 9/25/19 18:29, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> I see.? I dumped the redefinition count in the replay data because I 
>>> saw the other fields were dumped there.? Would they also not affect 
>>> the generated code?
>>>
>>> I can remove these changes.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>>
>> Rebuilt and retested with the ciReplay tests.? Thank you for looking 
>> at the change.
>> Coleen
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>>> make sense to me.? It won't affect the generated code, and we 
>>>> probably shouldn't even be installing/registering replay nmethods. 
>>>> I would remove the ciEnv::dump_replay_data_unsafe() and 
>>>> process_JvmtiExport() changes.
>>>>
>>>> dl
>>>>
>>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>>> compilation start.
>>>>>
>>>>> The bug was caused by a new nmethod created with an old Method in 
>>>>> the metadata section.? Added verification (which hit on windows) 
>>>>> and NSV in the other place where the method can be replaced in the 
>>>>> nmethod metadata section.
>>>>>
>>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might 
>>>>> be needed also in the graal compiler.
>>>>>
>>>>> Tested with tier1-6 and failing test 100 times.
>>>>>
>>>>> open webrev at 
>>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Sep 26 11:42:51 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 07:42:51 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <bbf73fd4-9e3c-4731-64db-4efb02dfbb4b@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <71903cf1-d532-ea9e-5c00-cf89652b11ac@oracle.com>
 <bbf73fd4-9e3c-4731-64db-4efb02dfbb4b@oracle.com>
Message-ID: <88246737-2bce-8066-b25f-249129afc5c9@oracle.com>



On 9/26/19 5:43 AM, erik.osterlund at oracle.com wrote:
> Hi Coleen,
>
> Could you please make the counter uint64_t instead? We usually use 64 
> bit unsigned counters when we don't want to think about overflow. 
> Otherwise I like the approach. Don't need another webrev... This looks 
> good.

You are right. I don't want to think about overflow for int for number 
of redefinitions.? I changed it to uint64_t and am rerunning tier1 on 
Oracle platforms just to be sure.

http://cr.openjdk.java.net/~coleenp/2019/8226690.03/webrev

Thanks,
Coleen
>
> Thanks,
> /Erik
>
> On 9/26/19 3:29 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> I see.? I dumped the redefinition count in the replay data because I 
>>> saw the other fields were dumped there.? Would they also not affect 
>>> the generated code?
>>>
>>> I can remove these changes.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>>
>> Rebuilt and retested with the ciReplay tests.? Thank you for looking 
>> at the change.
>> Coleen
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>>> make sense to me.? It won't affect the generated code, and we 
>>>> probably shouldn't even be installing/registering replay nmethods. 
>>>> I would remove the ciEnv::dump_replay_data_unsafe() and 
>>>> process_JvmtiExport() changes.
>>>>
>>>> dl
>>>>
>>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>>> compilation start.
>>>>>
>>>>> The bug was caused by a new nmethod created with an old Method in 
>>>>> the metadata section.? Added verification (which hit on windows) 
>>>>> and NSV in the other place where the method can be replaced in the 
>>>>> nmethod metadata section.
>>>>>
>>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might 
>>>>> be needed also in the graal compiler.
>>>>>
>>>>> Tested with tier1-6 and failing test 100 times.
>>>>>
>>>>> open webrev at 
>>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>
>>>
>>


From coleen.phillimore at oracle.com  Thu Sep 26 11:43:31 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 07:43:31 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <b77122d9-e2ac-99f4-593a-1692e7f4079e@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <65a6d23a-95d3-a040-f7af-21c6e989ffb1@oracle.com>
 <0238524d-f13f-8a4a-04c8-195f1d8f6820@oracle.com>
 <b77122d9-e2ac-99f4-593a-1692e7f4079e@oracle.com>
Message-ID: <ed180fbd-6779-6119-c476-5951f3082717@oracle.com>



On 9/26/19 12:01 AM, dean.long at oracle.com wrote:
> On 9/25/19 6:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> I see.? I dumped the redefinition count in the replay data because I 
>> saw the other fields were dumped there.? Would they also not affect 
>> the generated code?
>>
>
> I know some like _jvmti_can_access_local_variables can affect the 
> generated code.? See
>
> https://github.com/openjdk/jdk/blob/c83c8515ebb4e49fb63c9b896581c9f056268aa0/src/hotspot/share/ci/ciEnv.hpp#L344 
>

I see.? Thank you for reviewing the change and your comments.
Coleen

>
> dl
>> I can remove these changes.
>>
>> Thanks,
>> Coleen
>>
>> On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
>>> Saving and restoring redefinition_count for compiler replay doesn't 
>>> make sense to me.? It won't affect the generated code, and we 
>>> probably shouldn't even be installing/registering replay nmethods. I 
>>> would remove the ciEnv::dump_replay_data_unsafe() and 
>>> process_JvmtiExport() changes.
>>>
>>> dl
>>>
>>> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>> compilation start.
>>>>
>>>> The bug was caused by a new nmethod created with an old Method in 
>>>> the metadata section.? Added verification (which hit on windows) 
>>>> and NSV in the other place where the method can be replaced in the 
>>>> nmethod metadata section.
>>>>
>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>>> needed also in the graal compiler.
>>>>
>>>> Tested with tier1-6 and failing test 100 times.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>
>


From coleen.phillimore at oracle.com  Thu Sep 26 11:45:43 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 07:45:43 -0400
Subject: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata
In-Reply-To: <1270661a-db22-894d-6208-65251afe8022@oracle.com>
References: <4a945b40-0bf1-5990-ae51-f34bbd54bb0c@oracle.com>
 <4a6b74ab-f235-fb15-50b6-9bf1acee67d9@oracle.com>
 <4cfb7468-a19c-8741-f476-a72325a5d967@oracle.com>
 <1270661a-db22-894d-6208-65251afe8022@oracle.com>
Message-ID: <5b71031b-75f5-c448-c1db-dc61ed206af6@oracle.com>

Thanks Gilles.
Coleen

On 9/26/19 5:53 AM, Gilles Duboscq wrote:
> The JVMCI changes look good.
>
> Thank you,
> ?Gilles
>
> On 25/09/2019 21:53, coleen.phillimore at oracle.com wrote:
>> Thanks Gilles, I'll remove it from vmStructs_jvmci.cpp. So the jvmci 
>> code looks good?
>> thanks,
>> Coleen
>>
>> On 9/25/19 11:26 AM, Gilles Duboscq wrote:
>>> It looks to me like `_jvmti_redefinition_count` only needs to be 
>>> checked for consistency during code installation (which you do in 
>>> jvmciEnv & ciEnv).
>>> The compiler doesn't need to look at the value during the 
>>> compilation process so I don't think we need it in 
>>> `vmStructs_jvmci.cpp`.
>>>
>>> ?Gilles
>>>
>>> On 25/09/2019 16:33, coleen.phillimore at oracle.com wrote:
>>>> Summary: Dont create nmethod if classes have been redefined since 
>>>> compilation start.
>>>>
>>>> The bug was caused by a new nmethod created with an old Method in 
>>>> the metadata section.? Added verification (which hit on windows) 
>>>> and NSV in the other place where the method can be replaced in the 
>>>> nmethod metadata section.
>>>>
>>>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>>>> needed also in the graal compiler.
>>>>
>>>> Tested with tier1-6 and failing test 100 times.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>>>
>>>> Thanks,
>>>> Coleen
>>


From coleen.phillimore at oracle.com  Thu Sep 26 15:59:57 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Thu, 26 Sep 2019 11:59:57 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
Message-ID: <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>


For the record, I added volatiles after discussions with Goetz:

http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev

Which builds on s390 and ppc, and verified on Oracle platforms as well.

Coleen

On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
> Thanks Erik!
> Coleen
>
> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>> Hi Coleen,
>>
>> Looks good.
>>
>> Thanks,
>> /Erik
>>
>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>> Summary: allow old methods in 
>>> CompiledStaticDirectCall::set_to_interpreted
>>>
>>> This is the comment in the bug that describes this race and this fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>
>>>
>>> The rest of the bug and sightings are actually caused by 
>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>> and this one might have been caused by it also, but the race that 
>>> Erik describes is possible as well.
>>>
>>> The s390 code had an exception for callee->is_compiled_lambda_form() 
>>> which should probably apply to all the platforms, so the code is the 
>>> same on all the platforms with this change.
>>>
>>> Tested with tier1-6.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>
>>> Thanks,
>>> Coleen
>


From fujie at loongson.cn  Fri Sep 27 08:26:46 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 27 Sep 2019 16:26:46 +0800
Subject: RFR: 8231567: minimal build failed after JDK-8226690
Message-ID: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>

Hi all,

JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231567
Webrev: http://cr.openjdk.java.net/~jiefu/8231567/webrev.01/

Please review it and give me some advice.

Thanks a lot.
Best regards,
Jie



From glaubitz at physik.fu-berlin.de  Fri Sep 27 08:28:00 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 27 Sep 2019 10:28:00 +0200
Subject: Zero crashing on Linux-sparc with gcc-9
In-Reply-To: <36362b68-cfce-e159-8fa7-26549263d6db@redhat.com>
References: <4299d14c-53a8-8073-63cb-678b671f0810@physik.fu-berlin.de>
 <e9235024-b62c-eb14-d99e-98a0b5474071@physik.fu-berlin.de>
 <a54640d3-173e-7657-77d8-dcf1ff463ba3@redhat.com>
 <94ddbf3c-a9b4-a71a-7e9f-5d678b52e279@physik.fu-berlin.de>
 <36362b68-cfce-e159-8fa7-26549263d6db@redhat.com>
Message-ID: <80e30d50-13d8-e9f8-d6a6-4b9cfc880c41@physik.fu-berlin.de>

Hi Andrew!

On 9/25/19 7:28 PM, Andrew Haley wrote:
>> Care to elaborate? What are the pointers in your opinion? It builds fine
>> with gcc-7 and it used to build fine with older snapshot versions of
>> gcc-8. I haven't tracked down yet which gcc patch introduced the
>> breakage.
> 
> It could be a bug in the JVM. I have recently debugged problems which
> were due to undefined behaviour in HotSpot. It wouldn't be a terrible
> idea to run with GCC's UB Sanitizer and fix a few of the bugs.

Thanks for the pointers. I will have another look next week at the issue
and see if I can find something in the JVM code with the UB sanitizer.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From shade at redhat.com  Fri Sep 27 08:54:45 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 27 Sep 2019 10:54:45 +0200
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
Message-ID: <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>

On 9/27/19 10:26 AM, Jie Fu wrote:
> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231567
> Webrev: http://cr.openjdk.java.net/~jiefu/8231567/webrev.01/

Looks fine, as it matches what has_redefined_a_class() already does. The current uses of
JvmtiExport::redefinition_count() seem innocuous to handle 0.

-- 
Thanks,
-Aleksey


From fujie at loongson.cn  Fri Sep 27 09:42:53 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 27 Sep 2019 17:42:53 +0800
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
 <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
Message-ID: <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>

Thanks Aleksey.

On 2019/9/27 ??4:54, Aleksey Shipilev wrote:
> On 9/27/19 10:26 AM, Jie Fu wrote:
>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8231567
>> Webrev: http://cr.openjdk.java.net/~jiefu/8231567/webrev.01/
> Looks fine, as it matches what has_redefined_a_class() already does. The current uses of
> JvmtiExport::redefinition_count() seem innocuous to handle 0.
>


From matthias.baesken at sap.com  Fri Sep 27 10:56:58 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 27 Sep 2019 10:56:58 +0000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
 <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>
Message-ID: <VI1PR02MB508670406E7EDC489730E96293810@VI1PR02MB5086.eurprd02.prod.outlook.com>

Hi David /  Mikhailo ,  I  adjusted the test a bit more , and also  added   (+enabled) UL-based   jfr,event  tracing  in src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp
  to better see  the recorded event information .  

The current revision

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

sends   DatagramPackets   to     all     InetAddresses     of    all   network interfaces  of the machine  .
I observed  that on our "problematic" machine  where the test  fails  we still need a little  delay   to see the   read / write   counters   (fetched by os_perf and then used in the JFR)
   increase on the machine ( that?s why I wait a bit before every send operation).

Could you  please  check   8229370.3    also in your infrastructure where you noticed   sporadic failures   in  jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java   and tell me
 about the results ?


Best regards, Matthias


> Subject: Re: RFR [XS]: 8229370: make
> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
> 
> Hi Matthias,
> 
> On 24/09/2019 12:23 am, Baesken, Matthias wrote:
> > Hi David /  Mikhailo , I was busy with other tasks  but today  got back to
> 8229370 .
> >
> > I noticed that in the meantime,   the test was excluded  with
> >
> > https://bugs.openjdk.java.net/browse/JDK-8230115
> >
> > "Problemlist JFR TestNetworkUtilization test"
> >
> >
> > Do you think we still should  rely  on the OS counters , and expect to get  2+
> network interfaces,  or  keep  the test excluded (or just relax  the check and
> check for 1+  network interfaces on Linux)  ?
> 
> Exclusion is just a temporary measure to clean up the testing results,
> so this still needs to be fixed. I have nothing further to add from my
> comments in the bug:
> 
>  > So it should be as simple as changing 10.0.0.0:12345 into something
>  > guaranteed to work?
>  >
>  > I think this needs to be looked at by the JFR folk and net-dev folk to
>  > come up with a valid testing scenario.
> 
> It's not the number of interfaces that is the issue, it is generating
> traffic on the real interface.
> 
> Thanks,
> David
> 
> >
> > Best regards, Matthias
> >
> >
> >
> >>
> >> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
> >>> Hi David ,   I could  add some  optional  UL logging  to see   what happens.
> >>
> >> I just want to see more visibility at the test level to ensure it is
> >> finding the interfaces and addresses I would expect it to find.
> >>
> >> David
> >>
> >>> Maybe the  OS counters   that are fetched by   os_perf    are not that
> >> reliable on some  kernels .
> >>>
> >>>
> >>> Best regards, Matthias
> >>>
> >

From coleen.phillimore at oracle.com  Fri Sep 27 12:05:45 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 27 Sep 2019 08:05:45 -0400
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
 <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
 <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>
Message-ID: <18cbf369-6c3e-0535-71d5-182ee1f4bb33@oracle.com>

This looks good.? Sorry I didn't see this yesterday.

Coleen

On 9/27/19 5:42 AM, Jie Fu wrote:
> Thanks Aleksey.
>
> On 2019/9/27 ??4:54, Aleksey Shipilev wrote:
>> On 9/27/19 10:26 AM, Jie Fu wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231567
>>> Webrev: http://cr.openjdk.java.net/~jiefu/8231567/webrev.01/
>> Looks fine, as it matches what has_redefined_a_class() already does. 
>> The current uses of
>> JvmtiExport::redefinition_count() seem innocuous to handle 0.
>>
>


From erik.osterlund at oracle.com  Fri Sep 27 12:00:18 2019
From: erik.osterlund at oracle.com (erik.osterlund at oracle.com)
Date: Fri, 27 Sep 2019 14:00:18 +0200
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
Message-ID: <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>

Hi Coleen,

I don't understand this. It makes the frame-local variable volatile. But 
surely the frame local variable is accessed only by the current thread. 
And the whole thing is protected by the CompiledICLocker. Would you mind 
explaining what we are worried about here?

Thanks,
/Erik

On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>
> For the record, I added volatiles after discussions with Goetz:
>
> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>
> Which builds on s390 and ppc, and verified on Oracle platforms as well.
>
> Coleen
>
> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>> Thanks Erik!
>> Coleen
>>
>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>> Hi Coleen,
>>>
>>> Looks good.
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>> Summary: allow old methods in 
>>>> CompiledStaticDirectCall::set_to_interpreted
>>>>
>>>> This is the comment in the bug that describes this race and this fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>>
>>>>
>>>> The rest of the bug and sightings are actually caused by 
>>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>> and this one might have been caused by it also, but the race that 
>>>> Erik describes is possible as well.
>>>>
>>>> The s390 code had an exception for 
>>>> callee->is_compiled_lambda_form() which should probably apply to 
>>>> all the platforms, so the code is the same on all the platforms 
>>>> with this change.
>>>>
>>>> Tested with tier1-6.
>>>>
>>>> open webrev at 
>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>
>>>> Thanks,
>>>> Coleen
>>
>


From fujie at loongson.cn  Fri Sep 27 12:11:38 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 27 Sep 2019 20:11:38 +0800
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <18cbf369-6c3e-0535-71d5-182ee1f4bb33@oracle.com>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
 <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
 <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>
 <18cbf369-6c3e-0535-71d5-182ee1f4bb33@oracle.com>
Message-ID: <3e60f826-d5d9-db6b-0ed4-64721db01e1c@loongson.cn>

Hi Coleen,

Thanks for your review.

Updated: http://cr.openjdk.java.net/~jiefu/8231567/webrev.02/
- just added the reviewers

Could you please sponsor it?

Thanks a lot.
Best regards,
Jie

On 2019/9/27 ??8:05, coleen.phillimore at oracle.com wrote:
> This looks good.


From coleen.phillimore at oracle.com  Fri Sep 27 12:13:10 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 27 Sep 2019 08:13:10 -0400
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <3e60f826-d5d9-db6b-0ed4-64721db01e1c@loongson.cn>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
 <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
 <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>
 <18cbf369-6c3e-0535-71d5-182ee1f4bb33@oracle.com>
 <3e60f826-d5d9-db6b-0ed4-64721db01e1c@loongson.cn>
Message-ID: <efc6a836-0d89-7c53-80d3-11e34180bfca@oracle.com>

Yes, I'll sponsor it.
Coleen

On 9/27/19 8:11 AM, Jie Fu wrote:
> Hi Coleen,
>
> Thanks for your review.
>
> Updated: http://cr.openjdk.java.net/~jiefu/8231567/webrev.02/
> - just added the reviewers
>
> Could you please sponsor it?
>
> Thanks a lot.
> Best regards,
> Jie
>
> On 2019/9/27 ??8:05, coleen.phillimore at oracle.com wrote:
>> This looks good.
>


From coleen.phillimore at oracle.com  Fri Sep 27 12:18:42 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 27 Sep 2019 08:18:42 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
 <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
Message-ID: <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>



On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote:
> Hi Coleen,
>
> I don't understand this. It makes the frame-local variable volatile. 
> But surely the frame local variable is accessed only by the current 
> thread. And the whole thing is protected by the CompiledICLocker. 
> Would you mind explaining what we are worried about here?

The worry is that old_method would be fetched multiple times from data() 
in the assert.? Another thread could be updating data(), if I'm not 
mistaken.? Making destination volatile might not be necessary, but it 
was like that in s390, which experienced the race.

Coleen

>
> Thanks,
> /Erik
>
> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>>
>> For the record, I added volatiles after discussions with Goetz:
>>
>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>>
>> Which builds on s390 and ppc, and verified on Oracle platforms as well.
>>
>> Coleen
>>
>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>>> Thanks Erik!
>>> Coleen
>>>
>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>>> Hi Coleen,
>>>>
>>>> Looks good.
>>>>
>>>> Thanks,
>>>> /Erik
>>>>
>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>>> Summary: allow old methods in 
>>>>> CompiledStaticDirectCall::set_to_interpreted
>>>>>
>>>>> This is the comment in the bug that describes this race and this fix:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>>>
>>>>>
>>>>> The rest of the bug and sightings are actually caused by 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>>> and this one might have been caused by it also, but the race that 
>>>>> Erik describes is possible as well.
>>>>>
>>>>> The s390 code had an exception for 
>>>>> callee->is_compiled_lambda_form() which should probably apply to 
>>>>> all the platforms, so the code is the same on all the platforms 
>>>>> with this change.
>>>>>
>>>>> Tested with tier1-6.
>>>>>
>>>>> open webrev at 
>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>
>>
>


From fujie at loongson.cn  Fri Sep 27 12:22:50 2019
From: fujie at loongson.cn (Jie Fu)
Date: Fri, 27 Sep 2019 20:22:50 +0800
Subject: RFR: 8231567: minimal build failed after JDK-8226690
In-Reply-To: <efc6a836-0d89-7c53-80d3-11e34180bfca@oracle.com>
References: <7716fd67-9364-bc96-d784-65f1f94ee7c0@loongson.cn>
 <2915a585-0288-54e5-1750-903a3dbe6877@redhat.com>
 <da92d040-79b8-4df6-62bc-5d570e4164d0@loongson.cn>
 <18cbf369-6c3e-0535-71d5-182ee1f4bb33@oracle.com>
 <3e60f826-d5d9-db6b-0ed4-64721db01e1c@loongson.cn>
 <efc6a836-0d89-7c53-80d3-11e34180bfca@oracle.com>
Message-ID: <739ff754-d4dd-ba99-ecff-1b4ac98d4f62@loongson.cn>

Thanks Coleen.

On 2019/9/27 ??8:13, coleen.phillimore at oracle.com wrote:
> Yes, I'll sponsor it. 


From erik.osterlund at oracle.com  Fri Sep 27 13:20:39 2019
From: erik.osterlund at oracle.com (erik.osterlund at oracle.com)
Date: Fri, 27 Sep 2019 15:20:39 +0200
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
 <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
 <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>
Message-ID: <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com>

For any race to be observed, wouldn't we need to have concurrent writes 
not protected by the CompiledICLocker? If that indeed happens, then that 
seems like a bug, right? Or maybe I'm missing something.

/Erik

On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote:
>> Hi Coleen,
>>
>> I don't understand this. It makes the frame-local variable volatile. 
>> But surely the frame local variable is accessed only by the current 
>> thread. And the whole thing is protected by the CompiledICLocker. 
>> Would you mind explaining what we are worried about here?
>
> The worry is that old_method would be fetched multiple times from 
> data() in the assert.? Another thread could be updating data(), if I'm 
> not mistaken.? Making destination volatile might not be necessary, but 
> it was like that in s390, which experienced the race.
>
> Coleen
>
>>
>> Thanks,
>> /Erik
>>
>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>>>
>>> For the record, I added volatiles after discussions with Goetz:
>>>
>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>>>
>>> Which builds on s390 and ppc, and verified on Oracle platforms as well.
>>>
>>> Coleen
>>>
>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>>>> Thanks Erik!
>>>> Coleen
>>>>
>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>>>> Hi Coleen,
>>>>>
>>>>> Looks good.
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>>>> Summary: allow old methods in 
>>>>>> CompiledStaticDirectCall::set_to_interpreted
>>>>>>
>>>>>> This is the comment in the bug that describes this race and this 
>>>>>> fix:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>>>>
>>>>>>
>>>>>> The rest of the bug and sightings are actually caused by 
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>>>> and this one might have been caused by it also, but the race that 
>>>>>> Erik describes is possible as well.
>>>>>>
>>>>>> The s390 code had an exception for 
>>>>>> callee->is_compiled_lambda_form() which should probably apply to 
>>>>>> all the platforms, so the code is the same on all the platforms 
>>>>>> with this change.
>>>>>>
>>>>>> Tested with tier1-6.
>>>>>>
>>>>>> open webrev at 
>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>>>
>>>>>> Thanks,
>>>>>> Coleen
>>>>
>>>
>>
>


From coleen.phillimore at oracle.com  Fri Sep 27 13:46:51 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 27 Sep 2019 09:46:51 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
 <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
 <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>
 <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com>
Message-ID: <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com>



On 9/27/19 9:20 AM, erik.osterlund at oracle.com wrote:
> For any race to be observed, wouldn't we need to have concurrent 
> writes not protected by the CompiledICLocker? If that indeed happens, 
> then that seems like a bug, right? Or maybe I'm missing something.

I can't actually answer that because I didn't observe the races. Was 
this always protected by the CompiledICLocker?

I can remove the volatiles if they are protected by the CompiledICLocker.

Coleen

>
> /Erik
>
> On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote:
>>> Hi Coleen,
>>>
>>> I don't understand this. It makes the frame-local variable volatile. 
>>> But surely the frame local variable is accessed only by the current 
>>> thread. And the whole thing is protected by the CompiledICLocker. 
>>> Would you mind explaining what we are worried about here?
>>
>> The worry is that old_method would be fetched multiple times from 
>> data() in the assert.? Another thread could be updating data(), if 
>> I'm not mistaken.? Making destination volatile might not be 
>> necessary, but it was like that in s390, which experienced the race.
>>
>> Coleen
>>
>>>
>>> Thanks,
>>> /Erik
>>>
>>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>> For the record, I added volatiles after discussions with Goetz:
>>>>
>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>>>>
>>>> Which builds on s390 and ppc, and verified on Oracle platforms as 
>>>> well.
>>>>
>>>> Coleen
>>>>
>>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>>>>> Thanks Erik!
>>>>> Coleen
>>>>>
>>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Looks good.
>>>>>>
>>>>>> Thanks,
>>>>>> /Erik
>>>>>>
>>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>>>>> Summary: allow old methods in 
>>>>>>> CompiledStaticDirectCall::set_to_interpreted
>>>>>>>
>>>>>>> This is the comment in the bug that describes this race and this 
>>>>>>> fix:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>>>>>
>>>>>>>
>>>>>>> The rest of the bug and sightings are actually caused by 
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>>>>> and this one might have been caused by it also, but the race 
>>>>>>> that Erik describes is possible as well.
>>>>>>>
>>>>>>> The s390 code had an exception for 
>>>>>>> callee->is_compiled_lambda_form() which should probably apply to 
>>>>>>> all the platforms, so the code is the same on all the platforms 
>>>>>>> with this change.
>>>>>>>
>>>>>>> Tested with tier1-6.
>>>>>>>
>>>>>>> open webrev at 
>>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>
>>>>
>>>
>>
>


From Craig.Condit at target.com  Fri Sep 27 16:01:59 2019
From: Craig.Condit at target.com (Craig.Condit)
Date: Fri, 27 Sep 2019 16:01:59 +0000
Subject: 100% cpu on arm32 in Service Thread
Message-ID: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>

It appears there is some sort of regression in serviceThread.cpp which consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor builds including AdoptOpenJDK and BellSoft). This is easily reproducible  -- I used multiple Raspberry Pis (2 and 3).

All java processes consume 100% of a core in "Service Thread". To reproduce, launch any long-running java process (such as jshell), and in another terminal, run "top -H" to view CPU usage by thread.

This does not occur on jdk 11 or jdk 12.

From stefan.reich.maker.of.eye at googlemail.com  Fri Sep 27 16:08:35 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 27 Sep 2019 18:08:35 +0200
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
References: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
Message-ID: <CAC2-jLFppAWRPPag0ZNOtQRGYJa5vMs1o=Hvbt+JrYd4xfRoOg@mail.gmail.com>

Hold on! This might be the same bug I am chasing - and seeing right now
again, in fact. This is on Linux with JDK 13 EA 31 and top -H:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND

18690 root      20   0 7750728 3,775g  37660 R 98,2 32,1  12638:21 G1
Conc#0

This is going on indefinitely as long as the JVM runs.

On Fri, 27 Sep 2019 at 18:03, Craig.Condit <Craig.Condit at target.com> wrote:

> It appears there is some sort of regression in serviceThread.cpp which
> consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor
> builds including AdoptOpenJDK and BellSoft). This is easily reproducible
> -- I used multiple Raspberry Pis (2 and 3).
>
> All java processes consume 100% of a core in "Service Thread". To
> reproduce, launch any long-running java process (such as jshell), and in
> another terminal, run "top -H" to view CPU usage by thread.
>
> This does not occur on jdk 11 or jdk 12.
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From Craig.Condit at target.com  Fri Sep 27 16:22:49 2019
From: Craig.Condit at target.com (Craig.Condit)
Date: Fri, 27 Sep 2019 16:22:49 +0000
Subject: 100% cpu on arm32 in Service Thread
Message-ID: <40547437-1AEF-4FEF-97C7-2E942230F65F@target.com>

Hmm,

Are you sure? Your CPU usage seems to be occurring in a G1 thread, while mine is in Service Thread:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 7842 ccondit   20   0  328336  81768  11296 R  99.9   8.7   0:28.51 Service Thread
 7865 ccondit   20   0  309592  21168  10744 R  99.7   2.2   0:28.00 Service Thread

Simple command which triggers the issue (though any Java process I haved tried does the same):

$ /opt/openjdk-13/bin/jshell
|  Welcome to JShell -- Version 13
|  For an introduction type: /help intro

jshell>

Additional information:

$ /opt/openjdk-13/bin/java -version
openjdk version "13" 2019-09-17
OpenJDK Runtime Environment AdoptOpenJDK (build 13+33)
OpenJDK Server VM AdoptOpenJDK (build 13+33, mixed mode)

$ uname -a
Linux localhost.localdomain 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

$ lscpu
Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               4
Model name:          Cortex-A53
Stepping:            r0p4
CPU max MHz:         1200.0000
CPU min MHz:         600.0000
BogoMIPS:            76.80
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32


From: Stefan Reich <stefan.reich.maker.of.eye at googlemail.com>
Date: Friday, September 27, 2019 at 11:09 AM
To: "Craig.Condit" <Craig.Condit at target.com>
Cc: "hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>
Subject: [EXTERNAL] Re: 100% cpu on arm32 in Service Thread

Hold on! This might be the same bug I am chasing - and seeing right now again, in fact. This is on Linux with JDK 13 EA 31 and top -H:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
18690 root      20   0 7750728 3,775g  37660 R 98,2 32,1  12638:21 G1 Conc#0

This is going on indefinitely as long as the JVM runs.

On Fri, 27 Sep 2019 at 18:03, Craig.Condit <Craig.Condit at target.com<mailto:Craig.Condit at target.com>> wrote:
It appears there is some sort of regression in serviceThread.cpp which consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor builds including AdoptOpenJDK and BellSoft). This is easily reproducible  -- I used multiple Raspberry Pis (2 and 3).

All java processes consume 100% of a core in "Service Thread". To reproduce, launch any long-running java process (such as jshell), and in another terminal, run "top -H" to view CPU usage by thread.

This does not occur on jdk 11 or jdk 12.


--
Stefan Reich
BotCompany.de // Java-based operating systems

From stefan.reich.maker.of.eye at googlemail.com  Fri Sep 27 16:24:51 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Fri, 27 Sep 2019 18:24:51 +0200
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <40547437-1AEF-4FEF-97C7-2E942230F65F@target.com>
References: <40547437-1AEF-4FEF-97C7-2E942230F65F@target.com>
Message-ID: <CAC2-jLEcW6WoHDz191ZonXfszevPjxLT35bU2S2cKDOz6BVoqw@mail.gmail.com>

Yeah, probably a different bug... I'm just happy I'm zeroing in a little on
this bug. At least we now know it's most likely in G1.

I am possibly switching to ZGC BTW, but I'm still solving the multi-mapping
memory reporting problem on Linux.

On Fri, 27 Sep 2019 at 18:22, Craig.Condit <Craig.Condit at target.com> wrote:

> Hmm,
>
>
>
> Are you sure? Your CPU usage seems to be occurring in a G1 thread, while
> mine is in Service Thread:
>
>
>
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
> COMMAND
>
>  7842 ccondit   20   0  328336  81768  11296 R  99.9   8.7   0:28.51
> Service Thread
>
>  7865 ccondit   20   0  309592  21168  10744 R  99.7   2.2   0:28.00
> Service Thread
>
>
>
> Simple command which triggers the issue (though any Java process I haved
> tried does the same):
>
>
>
> $ /opt/openjdk-13/bin/jshell
>
> |  Welcome to JShell -- Version 13
>
> |  For an introduction type: /help intro
>
>
>
> jshell>
>
>
>
> Additional information:
>
>
>
> $ /opt/openjdk-13/bin/java -version
>
> openjdk version "13" 2019-09-17
>
> OpenJDK Runtime Environment AdoptOpenJDK (build 13+33)
>
> OpenJDK Server VM AdoptOpenJDK (build 13+33, mixed mode)
>
>
>
> $ uname -a
>
> Linux localhost.localdomain 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST
> 2019 armv7l GNU/Linux
>
>
>
> $ lscpu
>
> Architecture:        armv7l
>
> Byte Order:          Little Endian
>
> CPU(s):              4
>
> On-line CPU(s) list: 0-3
>
> Thread(s) per core:  1
>
> Core(s) per socket:  4
>
> Socket(s):           1
>
> Vendor ID:           ARM
>
> Model:               4
>
> Model name:          Cortex-A53
>
> Stepping:            r0p4
>
> CPU max MHz:         1200.0000
>
> CPU min MHz:         600.0000
>
> BogoMIPS:            76.80
>
> Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
> idiva idivt vfpd32 lpae evtstrm crc32
>
>
>
>
>
> *From: *Stefan Reich <stefan.reich.maker.of.eye at googlemail.com>
> *Date: *Friday, September 27, 2019 at 11:09 AM
> *To: *"Craig.Condit" <Craig.Condit at target.com>
> *Cc: *"hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>
> *Subject: *[EXTERNAL] Re: 100% cpu on arm32 in Service Thread
>
>
>
> Hold on! This might be the same bug I am chasing - and seeing right now
> again, in fact. This is on Linux with JDK 13 EA 31 and top -H:
>
>
>
>   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
>
> 18690 root      20   0 7750728 3,775g  37660 R 98,2 32,1  12638:21 G1
> Conc#0
>
>
>
> This is going on indefinitely as long as the JVM runs.
>
>
>
> On Fri, 27 Sep 2019 at 18:03, Craig.Condit <Craig.Condit at target.com>
> wrote:
>
> It appears there is some sort of regression in serviceThread.cpp which
> consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor
> builds including AdoptOpenJDK and BellSoft). This is easily reproducible
> -- I used multiple Raspberry Pis (2 and 3).
>
> All java processes consume 100% of a core in "Service Thread". To
> reproduce, launch any long-running java process (such as jshell), and in
> another terminal, run "top -H" to view CPU usage by thread.
>
> This does not occur on jdk 11 or jdk 12.
>
>
>
>
> --
>
> Stefan Reich
>
> BotCompany.de // Java-based operating systems
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems

From erik.osterlund at oracle.com  Fri Sep 27 16:32:43 2019
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 27 Sep 2019 18:32:43 +0200
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
 <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
 <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>
 <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com>
 <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com>
Message-ID: <41FDE810-C699-41C2-B4B9-F35E15818028@oracle.com>

Hi Coleen,

> On 27 Sep 2019, at 15:46, coleen.phillimore at oracle.com wrote:
> 
> 
> 
>> On 9/27/19 9:20 AM, erik.osterlund at oracle.com wrote:
>> For any race to be observed, wouldn't we need to have concurrent writes not protected by the CompiledICLocker? If that indeed happens, then that seems like a bug, right? Or maybe I'm missing something.
> 
> I can't actually answer that because I didn't observe the races. Was this always protected by the CompiledICLocker?

Yes.

> I can remove the volatiles if they are protected by the CompiledICLocker.

That would be great.

Thanks,
/Erik

> Coleen
> 
>> 
>> /Erik
>> 
>>> On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote:
>>> 
>>> 
>>>> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote:
>>>> Hi Coleen,
>>>> 
>>>> I don't understand this. It makes the frame-local variable volatile. But surely the frame local variable is accessed only by the current thread. And the whole thing is protected by the CompiledICLocker. Would you mind explaining what we are worried about here?
>>> 
>>> The worry is that old_method would be fetched multiple times from data() in the assert.  Another thread could be updating data(), if I'm not mistaken.  Making destination volatile might not be necessary, but it was like that in s390, which experienced the race.
>>> 
>>> Coleen
>>> 
>>>> 
>>>> Thanks,
>>>> /Erik
>>>> 
>>>>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>>>>> 
>>>>> For the record, I added volatiles after discussions with Goetz:
>>>>> 
>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>>>>> 
>>>>> Which builds on s390 and ppc, and verified on Oracle platforms as well.
>>>>> 
>>>>> Coleen
>>>>> 
>>>>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>>>>>> Thanks Erik!
>>>>>> Coleen
>>>>>> 
>>>>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>>>>>> Hi Coleen,
>>>>>>> 
>>>>>>> Looks good.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> /Erik
>>>>>>> 
>>>>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>> Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted
>>>>>>>> 
>>>>>>>> This is the comment in the bug that describes this race and this fix:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>>>>>>> 
>>>>>>>> The rest of the bug and sightings are actually caused by https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>>>>>> and this one might have been caused by it also, but the race that Erik describes is possible as well.
>>>>>>>> 
>>>>>>>> The s390 code had an exception for callee->is_compiled_lambda_form() which should probably apply to all the platforms, so the code is the same on all the platforms with this change.
>>>>>>>> 
>>>>>>>> Tested with tier1-6.
>>>>>>>> 
>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Coleen
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


From coleen.phillimore at oracle.com  Fri Sep 27 18:07:47 2019
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Fri, 27 Sep 2019 14:07:47 -0400
Subject: RFR (S) 8225681:
 vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe
 modification of inline cache
In-Reply-To: <41FDE810-C699-41C2-B4B9-F35E15818028@oracle.com>
References: <8cf70e41-46a0-27d3-1b74-ef0b94563e4a@oracle.com>
 <1669c73d-c118-3426-5b9c-35035f58042f@oracle.com>
 <0c2dd2ad-3395-ec3b-a503-c3ca6d866dc2@oracle.com>
 <15fc1133-1413-674a-770e-5b4de7a40baa@oracle.com>
 <e552c97d-b920-0083-7116-a207f8d7a978@oracle.com>
 <bb43825c-a351-1e65-f12d-8d4514e93668@oracle.com>
 <95832781-8566-f046-ebd4-d87a6f772f82@oracle.com>
 <7e7ff106-07b3-5096-38bb-6cca72aa57de@oracle.com>
 <41FDE810-C699-41C2-B4B9-F35E15818028@oracle.com>
Message-ID: <b5fec507-a1b7-1a96-5838-3803d2acabd7@oracle.com>


So I should have done this in the first place.? I consolidated the 
assert code and retested with Oracle platforms, aarch64 and zero.

open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.03/webrev

And the volatiles are gone.

Thanks,
Coleen

On 9/27/19 12:32 PM, Erik Osterlund wrote:
> Hi Coleen,
>
>> On 27 Sep 2019, at 15:46, coleen.phillimore at oracle.com wrote:
>>
>>
>>
>>> On 9/27/19 9:20 AM, erik.osterlund at oracle.com wrote:
>>> For any race to be observed, wouldn't we need to have concurrent writes not protected by the CompiledICLocker? If that indeed happens, then that seems like a bug, right? Or maybe I'm missing something.
>> I can't actually answer that because I didn't observe the races. Was this always protected by the CompiledICLocker?
> Yes.
>
>> I can remove the volatiles if they are protected by the CompiledICLocker.
> That would be great.
>
> Thanks,
> /Erik
>
>> Coleen
>>
>>> /Erik
>>>
>>>> On 9/27/19 2:18 PM, coleen.phillimore at oracle.com wrote:
>>>>
>>>>
>>>>> On 9/27/19 8:00 AM, erik.osterlund at oracle.com wrote:
>>>>> Hi Coleen,
>>>>>
>>>>> I don't understand this. It makes the frame-local variable volatile. But surely the frame local variable is accessed only by the current thread. And the whole thing is protected by the CompiledICLocker. Would you mind explaining what we are worried about here?
>>>> The worry is that old_method would be fetched multiple times from data() in the assert.  Another thread could be updating data(), if I'm not mistaken.  Making destination volatile might not be necessary, but it was like that in s390, which experienced the race.
>>>>
>>>> Coleen
>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>> On 9/26/19 5:59 PM, coleen.phillimore at oracle.com wrote:
>>>>>>
>>>>>> For the record, I added volatiles after discussions with Goetz:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~coleenp/2019/8225681.02/webrev
>>>>>>
>>>>>> Which builds on s390 and ppc, and verified on Oracle platforms as well.
>>>>>>
>>>>>> Coleen
>>>>>>
>>>>>>> On 9/26/19 7:24 AM, coleen.phillimore at oracle.com wrote:
>>>>>>> Thanks Erik!
>>>>>>> Coleen
>>>>>>>
>>>>>>>> On 9/26/19 5:47 AM, erik.osterlund at oracle.com wrote:
>>>>>>>> Hi Coleen,
>>>>>>>>
>>>>>>>> Looks good.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>>> On 9/25/19 11:22 PM, coleen.phillimore at oracle.com wrote:
>>>>>>>>> Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted
>>>>>>>>>
>>>>>>>>> This is the comment in the bug that describes this race and this fix:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441
>>>>>>>>>
>>>>>>>>> The rest of the bug and sightings are actually caused by https://bugs.openjdk.java.net/browse/JDK-8226690,
>>>>>>>>> and this one might have been caused by it also, but the race that Erik describes is possible as well.
>>>>>>>>>
>>>>>>>>> The s390 code had an exception for callee->is_compiled_lambda_form() which should probably apply to all the platforms, so the code is the same on all the platforms with this change.
>>>>>>>>>
>>>>>>>>> Tested with tier1-6.
>>>>>>>>>
>>>>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8225681.01/webrev
>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8225681
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Coleen


From glaubitz at physik.fu-berlin.de  Sat Sep 28 09:31:36 2019
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Sat, 28 Sep 2019 11:31:36 +0200
Subject: Taking up maintainership for SPARC - JEP-362
Message-ID: <7a270e82-b84f-c470-7bb0-86c2f7891b64@physik.fu-berlin.de>

Hello!

I have just been notified about JEP-362 [1] and would like to offer to be
the official maintainer of the SPARC ports of OpenJDK.

We're still using the Linux/SPARC port in Debian and therefore I would like
to help keeping the port in as long as possible. There might also be users
in the BSD world who are interested in the SPARC port.

Thanks,
Adrian

> [1] https://openjdk.java.net/jeps/362

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

From david.holmes at oracle.com  Sun Sep 29 00:17:00 2019
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 29 Sep 2019 10:17:00 +1000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <VI1PR02MB508670406E7EDC489730E96293810@VI1PR02MB5086.eurprd02.prod.outlook.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
 <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>
 <VI1PR02MB508670406E7EDC489730E96293810@VI1PR02MB5086.eurprd02.prod.outlook.com>
Message-ID: <6015a0d9-3ec9-ffb1-50da-b5723041c79c@oracle.com>

Hi Matthias,

On 27/09/2019 8:56 pm, Baesken, Matthias wrote:
> Hi David /  Mikhailo ,  I  adjusted the test a bit more , and also  added   (+enabled) UL-based   jfr,event  tracing  in src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp
>    to better see  the recorded event information .
> 
> The current revision
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.3/
> 
> sends   DatagramPackets   to     all     InetAddresses     of    all   network interfaces  of the machine  .
> I observed  that on our "problematic" machine  where the test  fails  we still need a little  delay   to see the   read / write   counters   (fetched by os_perf and then used in the JFR)
>     increase on the machine ( that?s why I wait a bit before every send operation).
> 
> Could you  please  check   8229370.3    also in your infrastructure where you noticed   sporadic failures   in  jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java   and tell me
>   about the results ?

I've submitted a test run to our system.

I'm unclear about the details of the test. Does this:

  77         Stream<InetAddress> si = 
NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses);

not also return the loopback address that was already tested? Could it 
return interfaces that we really don't want to be trying to test?

  88             } catch(IOException ioe) {
  89             }

Why are we silently swallowing exceptions here?

Thanks,
David

> 
> Best regards, Matthias
> 
> 
>> Subject: Re: RFR [XS]: 8229370: make
>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
>>
>> Hi Matthias,
>>
>> On 24/09/2019 12:23 am, Baesken, Matthias wrote:
>>> Hi David /  Mikhailo , I was busy with other tasks  but today  got back to
>> 8229370 .
>>>
>>> I noticed that in the meantime,   the test was excluded  with
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8230115
>>>
>>> "Problemlist JFR TestNetworkUtilization test"
>>>
>>>
>>> Do you think we still should  rely  on the OS counters , and expect to get  2+
>> network interfaces,  or  keep  the test excluded (or just relax  the check and
>> check for 1+  network interfaces on Linux)  ?
>>
>> Exclusion is just a temporary measure to clean up the testing results,
>> so this still needs to be fixed. I have nothing further to add from my
>> comments in the bug:
>>
>>   > So it should be as simple as changing 10.0.0.0:12345 into something
>>   > guaranteed to work?
>>   >
>>   > I think this needs to be looked at by the JFR folk and net-dev folk to
>>   > come up with a valid testing scenario.
>>
>> It's not the number of interfaces that is the issue, it is generating
>> traffic on the real interface.
>>
>> Thanks,
>> David
>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>>
>>>> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
>>>>> Hi David ,   I could  add some  optional  UL logging  to see   what happens.
>>>>
>>>> I just want to see more visibility at the test level to ensure it is
>>>> finding the interfaces and addresses I would expect it to find.
>>>>
>>>> David
>>>>
>>>>> Maybe the  OS counters   that are fetched by   os_perf    are not that
>>>> reliable on some  kernels .
>>>>>
>>>>>
>>>>> Best regards, Matthias
>>>>>
>>>

From david.holmes at oracle.com  Sun Sep 29 00:54:54 2019
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 29 Sep 2019 10:54:54 +1000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <6015a0d9-3ec9-ffb1-50da-b5723041c79c@oracle.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
 <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>
 <VI1PR02MB508670406E7EDC489730E96293810@VI1PR02MB5086.eurprd02.prod.outlook.com>
 <6015a0d9-3ec9-ffb1-50da-b5723041c79c@oracle.com>
Message-ID: <e4979379-6ebc-e6b8-aba2-b5d2de61a879@oracle.com>

Hi Matthias,

The test is sometimes failing on Windows (2 out of 5 runs):

java.lang.RuntimeException: No events: expected false, was true
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertFalse(Asserts.java:461)
	at jdk.test.lib.jfr.Events.hasEvents(Events.java:158)
	at 
jdk.jfr.event.runtime.TestNetworkUtilizationEvent.main(TestNetworkUtilizationEvent.java:98)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:830)

The main output shows we are duplicating the write to the loopback 
address and I think we're trying to write to too many interfaces:

----------System.out:(12/660)----------
[0.796s][trace][jfr,event] Reporting network utilization
[0.811s][trace][jfr,event] Reporting network utilization
InetAddress.getLoopbackAddress :localhost/127.0.0.1 host address:127.0.0.1
Sending to InetAddress:/127.0.0.1
Sending to InetAddress:/0:0:0:0:0:0:0:1
Sending to InetAddress:/<IPv4 address>
Sending to InetAddress:/<IPv6 addr>%eth4
Sending to InetAddress:/<IPv6 addr>
Sending to InetAddress:/<IPv6 add>%net5
[6.943s][trace][jfr,event] Reporting network utilization
[6.950s][trace][jfr,event] Reporting network utilization
[6.957s][trace][jfr,event] Reporting network utilization

On a passing test I see:

[6.947s][trace][jfr,event] Reporting network utilization
[6.947s][trace][jfr,event] found data for NetworkInterface Oracle VirtIO 
Ethernet Adapter (read_rate 19, write_rate 10)
[6.952s][trace][jfr,event] Reporting network utilization
[6.960s][trace][jfr,event] Reporting network utilization
jdk.NetworkUtilization {
   startTime = 00:36:46.904
   networkInterface = "Oracle VirtIO Ethernet Adapter"
   readRate = 152 bps
   writeRate = 80 bps
}

but I have no idea to which of the 6 INetAddress entries this corresponds.

David

On 29/09/2019 10:17 am, David Holmes wrote:
> Hi Matthias,
> 
> On 27/09/2019 8:56 pm, Baesken, Matthias wrote:
>> Hi David /? Mikhailo ,? I? adjusted the test a bit more , and also  
>> added?? (+enabled) UL-based?? jfr,event? tracing? in 
>> src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp
>> ?? to better see? the recorded event information .
>>
>> The current revision
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.3/
>>
>> sends?? DatagramPackets?? to???? all???? InetAddresses???? of??? all   
>> network interfaces? of the machine? .
>> I observed? that on our "problematic" machine? where the test? fails  
>> we still need a little? delay?? to see the?? read / write?? counters   
>> (fetched by os_perf and then used in the JFR)
>> ??? increase on the machine ( that?s why I wait a bit before every 
>> send operation).
>>
>> Could you? please? check?? 8229370.3??? also in your infrastructure 
>> where you noticed?? sporadic failures?? in  
>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java?? and tell me
>> ? about the results ?
> 
> I've submitted a test run to our system.
> 
> I'm unclear about the details of the test. Does this:
> 
>  ?77???????? Stream<InetAddress> si = 
> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses); 
> 
> 
> not also return the loopback address that was already tested? Could it 
> return interfaces that we really don't want to be trying to test?
> 
>  ?88???????????? } catch(IOException ioe) {
>  ?89???????????? }
> 
> Why are we silently swallowing exceptions here?
> 
> Thanks,
> David
> 
>>
>> Best regards, Matthias
>>
>>
>>> Subject: Re: RFR [XS]: 8229370: make
>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
>>>
>>> Hi Matthias,
>>>
>>> On 24/09/2019 12:23 am, Baesken, Matthias wrote:
>>>> Hi David /? Mikhailo , I was busy with other tasks? but today? got 
>>>> back to
>>> 8229370 .
>>>>
>>>> I noticed that in the meantime,?? the test was excluded? with
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8230115
>>>>
>>>> "Problemlist JFR TestNetworkUtilization test"
>>>>
>>>>
>>>> Do you think we still should? rely? on the OS counters , and expect 
>>>> to get? 2+
>>> network interfaces,? or? keep? the test excluded (or just relax? the 
>>> check and
>>> check for 1+? network interfaces on Linux)? ?
>>>
>>> Exclusion is just a temporary measure to clean up the testing results,
>>> so this still needs to be fixed. I have nothing further to add from my
>>> comments in the bug:
>>>
>>> ? > So it should be as simple as changing 10.0.0.0:12345 into something
>>> ? > guaranteed to work?
>>> ? >
>>> ? > I think this needs to be looked at by the JFR folk and net-dev 
>>> folk to
>>> ? > come up with a valid testing scenario.
>>>
>>> It's not the number of interfaces that is the issue, it is generating
>>> traffic on the real interface.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>>
>>>>> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
>>>>>> Hi David ,?? I could? add some? optional? UL logging? to see   
>>>>>> what happens.
>>>>>
>>>>> I just want to see more visibility at the test level to ensure it is
>>>>> finding the interfaces and addresses I would expect it to find.
>>>>>
>>>>> David
>>>>>
>>>>>> Maybe the? OS counters?? that are fetched by?? os_perf??? are not 
>>>>>> that
>>>>> reliable on some? kernels .
>>>>>>
>>>>>>
>>>>>> Best regards, Matthias
>>>>>>
>>>>

From david.holmes at oracle.com  Mon Sep 30 00:43:47 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Sep 2019 10:43:47 +1000
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
References: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
Message-ID: <25d47631-af2e-d6df-bb1d-829061dfa2e0@oracle.com>

Hi Craig,

On 28/09/2019 2:01 am, Craig.Condit wrote:
> It appears there is some sort of regression in serviceThread.cpp which consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor builds including AdoptOpenJDK and BellSoft). This is easily reproducible  -- I used multiple Raspberry Pis (2 and 3).
> 
> All java processes consume 100% of a core in "Service Thread". To reproduce, launch any long-running java process (such as jshell), and in another terminal, run "top -H" to view CPU usage by thread.
> 
> This does not occur on jdk 11 or jdk 12.

Doesn't occur on x86-32 either so seems to be arm32 specific. Which is a 
little odd as I can't see anything the serviceThread does that is 
obviously CPU dependent. Unfortunately there is no logging in the 
serviceThread itself so this would need some active debugging by the 
Bellsoft folk (as maintainers of the arm32 port). I've added Boris to 
the cc list.

Thanks for the report.

David

From aleksei.voitylov at bell-sw.com  Mon Sep 30 08:09:04 2019
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Mon, 30 Sep 2019 11:09:04 +0300
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
References: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
Message-ID: <0a31d963-8d55-1cdb-b136-0c463724c59d@bell-sw.com>

Craig,

Ouch. Here is a bug to track this issue: 
https://bugs.openjdk.java.net/browse/JDK-8231612

-Aleksei

On 27/09/2019 19:01, Craig.Condit wrote:
> It appears there is some sort of regression in serviceThread.cpp which consumes all available CPU on jdk13 arm32 builds (tested on multiple vendor builds including AdoptOpenJDK and BellSoft). This is easily reproducible  -- I used multiple Raspberry Pis (2 and 3).
>
> All java processes consume 100% of a core in "Service Thread". To reproduce, launch any long-running java process (such as jshell), and in another terminal, run "top -H" to view CPU usage by thread.
>
> This does not occur on jdk 11 or jdk 12.

From thomas.schatzl at oracle.com  Mon Sep 30 08:32:19 2019
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 30 Sep 2019 10:32:19 +0200
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <CAC2-jLFppAWRPPag0ZNOtQRGYJa5vMs1o=Hvbt+JrYd4xfRoOg@mail.gmail.com>
References: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
 <CAC2-jLFppAWRPPag0ZNOtQRGYJa5vMs1o=Hvbt+JrYd4xfRoOg@mail.gmail.com>
Message-ID: <efd68d48-fed6-a553-1a3a-64ac6de3ff8c@oracle.com>

Hi,

On 27.09.19 18:08, Stefan Reich wrote:
> Hold on! This might be the same bug I am chasing - and seeing right now
> again, in fact. This is on Linux with JDK 13 EA 31 and top -H:
> 
>    PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
> 
> 18690 root      20   0 7750728 3,775g  37660 R 98,2 32,1  12638:21 G1
> Conc#0
> 
> This is going on indefinitely as long as the JVM runs.

   can you give more details about the platform (x64?) and program you 
used to reproduce this?

Does it reproduce with jdk13 build 33 (the ga build)?

Thanks,
   Thomas

From matthias.baesken at sap.com  Mon Sep 30 10:14:05 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 30 Sep 2019 10:14:05 +0000
Subject: RFR [XS]: 8229370: make
 jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
In-Reply-To: <e4979379-6ebc-e6b8-aba2-b5d2de61a879@oracle.com>
References: <AM6PR02MB507849159D0A125C0F3592DE93A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com>
 <AM6PR02MB5078855420A625F427EF396393A00@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <5D6596DD.5090602@oracle.com>
 <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com>
 <ebeb9cf4-7191-1071-4d25-a8c932b46778@oracle.com>
 <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com>
 <AM6PR02MB507868DE73FF519910C45EF693A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com>
 <AM6PR02MB5078E0E174568F621CEC703B93A30@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a779a394-34f6-1fee-97a5-a5add3f624eb@oracle.com>
 <AM6PR02MB5078909F231B38F8D3F88E9593850@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <a273212a-5070-4e98-9939-39ca67c16bb7@oracle.com>
 <VI1PR02MB508670406E7EDC489730E96293810@VI1PR02MB5086.eurprd02.prod.outlook.com>
 <6015a0d9-3ec9-ffb1-50da-b5723041c79c@oracle.com>
 <e4979379-6ebc-e6b8-aba2-b5d2de61a879@oracle.com>
Message-ID: <AM6PR02MB5078BEA8301220D2688B175293820@AM6PR02MB5078.eurprd02.prod.outlook.com>

>
> I'm unclear about the details of the test. Does this:
>  77         Stream<InetAddress> si = NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses);
> not also return the loopback address that was already tested? Could it 
> return interfaces that we really don't want to be trying to test?

Hi David, 
   yes we are sending to all Inetadresses of all adapters  ( at least   the ones  that are not in status DOWN,   I noticed  that  the Java/net JDK classes  omit  those on Linux ).
I think it is not a bad idea to send to all to get the "right"  one  but maybe the original  test owners  might comment on this .

  88             } catch(IOException ioe) {
  89             }

> Why are we silently swallowing exceptions here?

I agree , we should at least give some output for this case of send failures .

> The test is sometimes failing on Windows (2 out of 5 runs):

Thanks for testing !
 Bad to hear about the failures ,   is it failing too  without my  patch ?  It might be a separate issue  you observe .

Events.hasEvents(events);     fails in your  example below  looking at the stacktrace  -  there seems to be something  very wrong with the JFR event  generating and/or capturing on the machine you test .

Best regards, Matthias


> 
> Hi Matthias,
> 
> The test is sometimes failing on Windows (2 out of 5 runs):
> 
> java.lang.RuntimeException: No events: expected false, was true
> 	at jdk.test.lib.Asserts.fail(Asserts.java:594)
> 	at jdk.test.lib.Asserts.assertFalse(Asserts.java:461)
> 	at jdk.test.lib.jfr.Events.hasEvents(Events.java:158)
> 	at
> jdk.jfr.event.runtime.TestNetworkUtilizationEvent.main(TestNetworkUtiliza
> tionEvent.java:98)
> 	at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> 	at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
> hodAccessorImpl.java:62)
> 	at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega
> tingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp
> er.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:830)
> 
> The main output shows we are duplicating the write to the loopback
> address and I think we're trying to write to too many interfaces:
> 
> ----------System.out:(12/660)----------
> [0.796s][trace][jfr,event] Reporting network utilization
> [0.811s][trace][jfr,event] Reporting network utilization
> InetAddress.getLoopbackAddress :localhost/127.0.0.1 host address:127.0.0.1
> Sending to InetAddress:/127.0.0.1
> Sending to InetAddress:/0:0:0:0:0:0:0:1
> Sending to InetAddress:/<IPv4 address>
> Sending to InetAddress:/<IPv6 addr>%eth4
> Sending to InetAddress:/<IPv6 addr>
> Sending to InetAddress:/<IPv6 add>%net5
> [6.943s][trace][jfr,event] Reporting network utilization
> [6.950s][trace][jfr,event] Reporting network utilization
> [6.957s][trace][jfr,event] Reporting network utilization
> 
> On a passing test I see:
> 
> [6.947s][trace][jfr,event] Reporting network utilization
> [6.947s][trace][jfr,event] found data for NetworkInterface Oracle VirtIO
> Ethernet Adapter (read_rate 19, write_rate 10)
> [6.952s][trace][jfr,event] Reporting network utilization
> [6.960s][trace][jfr,event] Reporting network utilization
> jdk.NetworkUtilization {
>    startTime = 00:36:46.904
>    networkInterface = "Oracle VirtIO Ethernet Adapter"
>    readRate = 152 bps
>    writeRate = 80 bps
> }
> 
> but I have no idea to which of the 6 INetAddress entries this corresponds.
> 
> David
> 
> On 29/09/2019 10:17 am, David Holmes wrote:
> > Hi Matthias,
> >
> > On 27/09/2019 8:56 pm, Baesken, Matthias wrote:
> >> Hi David /? Mikhailo ,? I? adjusted the test a bit more , and also
> >> added?? (+enabled) UL-based?? jfr,event? tracing? in
> >> src/hotspot/share/jfr/periodic/jfrNetworkUtilization.cpp
> >> ?? to better see? the recorded event information .
> >>
> >> The current revision
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.3/
> >>
> >> sends?? DatagramPackets?? to???? all???? InetAddresses???? of??? all
> >> network interfaces? of the machine? .
> >> I observed? that on our "problematic" machine? where the test? fails
> >> we still need a little? delay?? to see the?? read / write?? counters
> >> (fetched by os_perf and then used in the JFR)
> >> ??? increase on the machine ( that?s why I wait a bit before every
> >> send operation).
> >>
> >> Could you? please? check?? 8229370.3??? also in your infrastructure
> >> where you noticed?? sporadic failures?? in
> >> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java?? and tell me
> >> ? about the results ?
> >
> > I've submitted a test run to our system.
> >
> > I'm unclear about the details of the test. Does this:
> >
> >  ?77???????? Stream<InetAddress> si =
> >
> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr
> esses);
> >
> >
> > not also return the loopback address that was already tested? Could it
> > return interfaces that we really don't want to be trying to test?
> >
> >  ?88???????????? } catch(IOException ioe) {
> >  ?89???????????? }
> >
> > Why are we silently swallowing exceptions here?
> >
> > Thanks,
> > David
> >
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> Subject: Re: RFR [XS]: 8229370: make
> >>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable
> >>>
> >>> Hi Matthias,
> >>>
> >>> On 24/09/2019 12:23 am, Baesken, Matthias wrote:
> >>>> Hi David /? Mikhailo , I was busy with other tasks? but today? got
> >>>> back to
> >>> 8229370 .
> >>>>
> >>>> I noticed that in the meantime,?? the test was excluded? with
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8230115
> >>>>
> >>>> "Problemlist JFR TestNetworkUtilization test"
> >>>>
> >>>>
> >>>> Do you think we still should? rely? on the OS counters , and expect
> >>>> to get? 2+
> >>> network interfaces,? or? keep? the test excluded (or just relax? the
> >>> check and
> >>> check for 1+? network interfaces on Linux)? ?
> >>>
> >>> Exclusion is just a temporary measure to clean up the testing results,
> >>> so this still needs to be fixed. I have nothing further to add from my
> >>> comments in the bug:
> >>>
> >>> ? > So it should be as simple as changing 10.0.0.0:12345 into something
> >>> ? > guaranteed to work?
> >>> ? >
> >>> ? > I think this needs to be looked at by the JFR folk and net-dev
> >>> folk to
> >>> ? > come up with a valid testing scenario.
> >>>
> >>> It's not the number of interfaces that is the issue, it is generating
> >>> traffic on the real interface.
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>>>
> >>>> Best regards, Matthias
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> On 29/08/2019 12:24 am, Baesken, Matthias wrote:
> >>>>>> Hi David ,?? I could? add some? optional? UL logging? to see
> >>>>>> what happens.
> >>>>>
> >>>>> I just want to see more visibility at the test level to ensure it is
> >>>>> finding the interfaces and addresses I would expect it to find.
> >>>>>
> >>>>> David
> >>>>>
> >>>>>> Maybe the? OS counters?? that are fetched by?? os_perf??? are not
> >>>>>> that
> >>>>> reliable on some? kernels .
> >>>>>>
> >>>>>>
> >>>>>> Best regards, Matthias
> >>>>>>
> >>>>

From dkwakkel at gmail.com  Mon Sep 30 12:46:50 2019
From: dkwakkel at gmail.com (Donald Kwakkel)
Date: Mon, 30 Sep 2019 14:46:50 +0200
Subject: No subject
Message-ID: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>

Is this a known issue / are there workarounds?

If during malloc a crash signal occurs, the jvm will hang because it will
call again malloc, which is not reentrant (for explanation see
https://stackoverflow.com/questions/40049751/malloc-inside-linux-signal-handler-cause-deadlock).


This is for production environments a big problem because self-healing (in
this case an automatic restart through jsvc) will not work. Resulting in
manual actions by cloud administrators!

Thread 84 (Thread 0x7f110f2c0700 (LWP 17574)):
#0  0x0000003ce2cf542e in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x0000003ce2c7bed5 in _L_lock_9323 () from /lib64/libc.so.6
#2  0x0000003ce2c797c6 in malloc () from /lib64/libc.so.6
#3  0x00007f123a7cb7d5 in os::malloc(unsigned long, MemoryType,
NativeCallStack const&) () from /usr/java/latest/lib/server/libjvm.so
#4  0x00007f1239fd7610 in AllocateHeap(unsigned long, MemoryType,
AllocFailStrategy::AllocFailEnum) () from
/usr/java/latest/lib/server/libjvm.so
#5  0x00007f123a271d48 in Decoder::decode(unsigned char*, char*, int,
int*, char const*, bool) () from /usr/java/latest/lib/server/libjvm.so
#6  0x00007f123a7d42ea in os::dll_address_to_function_name(unsigned
char*, char*, int, int*, bool) () from
/usr/java/latest/lib/server/libjvm.so
#7  0x00007f123a32b824 in frame::print_C_frame(outputStream*, char*,
int, unsigned char*) () from /usr/java/latest/lib/server/libjvm.so
#8  0x00007f123a9f7b84 in VMError::report(outputStream*, bool) () from
/usr/java/latest/lib/server/libjvm.so
#9  0x00007f123a9fb4f6 in VMError::report_and_die(int, char const*,
char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*,
char const*, int, unsigned long) ()
   from /usr/java/latest/lib/server/libjvm.so
#10 0x00007f123a9fbb7b in VMError::report_and_die(Thread*, unsigned
int, unsigned char*, void*, void*, char const*, ...) () from
/usr/java/latest/lib/server/libjvm.so
#11 0x00007f123a9fbbae in VMError::report_and_die(Thread*, unsigned
int, unsigned char*, void*, void*) () from
/usr/java/latest/lib/server/libjvm.so
#12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
/usr/java/latest/lib/server/libjvm.so
#13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
/usr/java/latest/lib/server/libjvm.so
#14 <signal handler called>
#15 0x0000003ce2c7856c in _int_malloc () from /lib64/libc.so.6
#16 0x0000003ce2c797d1 in malloc () from /lib64/libc.so.6
#17 0x00007f123a7cb6ba in os::malloc(unsigned long, MemoryType) ()
from /usr/java/latest/lib/server/libjvm.so
#18 0x00007f123a5bd661 in JvmtiEnv::Allocate(long, unsigned char**) ()
from /usr/java/latest/lib/server/libjvm.so
#19 0x00007f123a579adf in jvmti_Allocate () from
/usr/java/latest/lib/server/libjvm.so
#20 0x00007f1238f2138d in jvmtiAllocate () from /opt/jdk-11/lib/libjdwp.so
#21 0x00007f1238f04d3e in classTrack_processUnloads () from
/opt/jdk-11/lib/libjdwp.so
#22 0x00007f1238f0cdbb in event_callback () from /opt/jdk-11/lib/libjdwp.so
#23 0x00007f1238f0dd7b in cbThreadEnd () from /opt/jdk-11/lib/libjdwp.so
#24 0x00007f123a5d68ff in JvmtiExport::post_thread_end(JavaThread*) ()
from /usr/java/latest/lib/server/libjvm.so
#25 0x00007f123a996836 in JavaThread::exit(bool, JavaThread::ExitType)
() from /usr/java/latest/lib/server/libjvm.so
#26 0x00007f123a996c96 in JavaThread::thread_main_inner() () from
/usr/java/latest/lib/server/libjvm.so
#27 0x00007f123a997177 in JavaThread::run() () from
/usr/java/latest/lib/server/libjvm.so
#28 0x00007f123a7dc7d0 in thread_native_entry(Thread*) () from
/usr/java/latest/lib/server/libjvm.so
#29 0x0000003ce34077f1 in start_thread () from /lib64/libpthread.so.0
#30 0x0000003ce2ce5ccd in clone () from /lib64/libc.so.6

See similair openjdk bug: https://bugs.openjdk.java.net/browse/JDK-8156823
java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

From fweimer at redhat.com  Mon Sep 30 12:55:31 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 30 Sep 2019 14:55:31 +0200
Subject: none
In-Reply-To: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 (Donald Kwakkel's message of "Mon, 30 Sep 2019 14:46:50 +0200")
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
Message-ID: <87impa2bb0.fsf@oldenburg2.str.redhat.com>

* Donald Kwakkel:

> Is this a known issue / are there workarounds?

Yes, sort of, we've seen it many times with in-process crash handlers.

> If during malloc a crash signal occurs, the jvm will hang because it will
> call again malloc, which is not reentrant (for explanation see
> https://stackoverflow.com/questions/40049751/malloc-inside-linux-signal-handler-cause-deadlock).
>
>
> This is for production environments a big problem because self-healing (in
> this case an automatic restart through jsvc) will not work. Resulting in
> manual actions by cloud administrators!

The recommended practice is to use a crash handler external to the
process.  Of course, this is not going to fix the underlying issue which
causes the crash.

> #11 0x00007f123a9fbbae in VMError::report_and_die(Thread*, unsigned
> int, unsigned char*, void*, void*) () from
> /usr/java/latest/lib/server/libjvm.so
> #12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
> /usr/java/latest/lib/server/libjvm.so
> #13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
> /usr/java/latest/lib/server/libjvm.so
> #14 <signal handler called>
> #15 0x0000003ce2c7856c in _int_malloc () from /lib64/libc.so.6

The question is whether a verbose crash report is actually needed if the
PC value (as recorded in the siginfo* argument) is within libc.so.6.
Maybe in this case, a more limited crash dump is appropriate.

Thanks,
Florian

From david.holmes at oracle.com  Mon Sep 30 13:12:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Sep 2019 23:12:41 +1000
Subject: none
In-Reply-To: <87impa2bb0.fsf@oldenburg2.str.redhat.com>
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 <87impa2bb0.fsf@oldenburg2.str.redhat.com>
Message-ID: <9c03a2d3-bcd3-9ac2-04f3-9e998389c8b5@oracle.com>

On 30/09/2019 10:55 pm, Florian Weimer wrote:
> * Donald Kwakkel:
> 
>> Is this a known issue / are there workarounds?
> 
> Yes, sort of, we've seen it many times with in-process crash handlers.

We all know that there are many many things that you cannot safely do 
from a signal handling context, but if we stuck to what was safe it 
would not be possible to produce anything like a meaningful error report 
(though I've voiced concern that more and more and more keeps getting 
added to the error reporting!). But the error report is primarily 
intended to help diagnose problems within the JVM, or the JDK libraries, 
we're not expecting to hit faults in libc, or other system libraries - 
and so reentrant mallocs is a very rare occurrence.

>> If during malloc a crash signal occurs, the jvm will hang because it will
>> call again malloc, which is not reentrant (for explanation see
>> https://stackoverflow.com/questions/40049751/malloc-inside-linux-signal-handler-cause-deadlock).
>>
>>
>> This is for production environments a big problem because self-healing (in
>> this case an automatic restart through jsvc) will not work. Resulting in
>> manual actions by cloud administrators!
> 
> The recommended practice is to use a crash handler external to the
> process.  Of course, this is not going to fix the underlying issue which
> causes the crash.
> 
>> #11 0x00007f123a9fbbae in VMError::report_and_die(Thread*, unsigned
>> int, unsigned char*, void*, void*) () from
>> /usr/java/latest/lib/server/libjvm.so
>> #12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
>> /usr/java/latest/lib/server/libjvm.so
>> #13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
>> /usr/java/latest/lib/server/libjvm.so
>> #14 <signal handler called>
>> #15 0x0000003ce2c7856c in _int_malloc () from /lib64/libc.so.6
> 
> The question is whether a verbose crash report is actually needed if the
> PC value (as recorded in the siginfo* argument) is within libc.so.6.
> Maybe in this case, a more limited crash dump is appropriate.

I think though, that by the time we have enough information to figure 
that out it may already be too late - in this case the malloc is used by 
the Decoder which is being used to determine where the crash is IIUC. 
Though perhaps we need to look at the Decoder and see if we can use 
non-malloc'd memory.

Cheers,
David
-----

> Thanks,
> Florian
> 

From fweimer at redhat.com  Mon Sep 30 13:21:47 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 30 Sep 2019 15:21:47 +0200
Subject: Hotspot crash handler re-enters malloc
In-Reply-To: <9c03a2d3-bcd3-9ac2-04f3-9e998389c8b5@oracle.com> (David Holmes's
 message of "Mon, 30 Sep 2019 23:12:41 +1000")
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 <87impa2bb0.fsf@oldenburg2.str.redhat.com>
 <9c03a2d3-bcd3-9ac2-04f3-9e998389c8b5@oracle.com>
Message-ID: <8736gd3ono.fsf_-_@oldenburg2.str.redhat.com>

* David Holmes:

> We all know that there are many many things that you cannot safely do
> from a signal handling context, but if we stuck to what was safe it
> would not be possible to produce anything like a meaningful error
> report (though I've voiced concern that more and more and more keeps
> getting added to the error reporting!). But the error report is
> primarily intended to help diagnose problems within the JVM, or the
> JDK libraries, we're not expecting to hit faults in libc, or other
> system libraries - and so reentrant mallocs is a very rare occurrence.

It's not rare if something causes heap corruption, unfortunately.  On
the other hand, we have added more and more non-optional heap
consistency checks to glibc over time.  Those raise SIGABRT on failure
instead of crashing with SIGSEGV, and it appears that Hotspot doesn't
trigger the crash dump for that (which is a bit odd, but it does avoid
most of the malloc reentrancy issues).

>> The question is whether a verbose crash report is actually needed if the
>> PC value (as recorded in the siginfo* argument) is within libc.so.6.
>> Maybe in this case, a more limited crash dump is appropriate.
>
> I think though, that by the time we have enough information to figure
> that out it may already be too late - in this case the malloc is used
> by the Decoder which is being used to determine where the crash is
> IIUC. Though perhaps we need to look at the Decoder and see if we can
> use non-malloc'd memory.

If you read the PC from the siginfo * argument, you don't need the
decoder.  Obviously, you need to pre-record the libc.so.6 boundaries
somewhere so that you do not have to call into the dynamic loader at the
time of the crash.

But maybe that's not really helpful because too many SIGSEGV crashes
happen in libc.so.6 and the full dumps add value for diagnosing them.

Thanks,
Florian

From dkwakkel at gmail.com  Mon Sep 30 13:34:33 2019
From: dkwakkel at gmail.com (Donald Kwakkel)
Date: Mon, 30 Sep 2019 15:34:33 +0200
Subject: none
In-Reply-To: <87impa2bb0.fsf@oldenburg2.str.redhat.com>
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 <87impa2bb0.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAO7qondaCJuwUMts4K1TpVBb_Ys2bHGDzwS+h5FVcjh7kwsDoQ@mail.gmail.com>

So you mean that if jsvc is not used the hang will not occur? Because if I
look at the stack I do not see any jsvc related code executed.
(Indeed I am not looking howto make sure not to crash, but how to make sure
a crash will not hang).

Is it possible to disable the verbose crash report?

Op ma 30 sep. 2019 om 14:55 schreef Florian Weimer <fweimer at redhat.com>:

> * Donald Kwakkel:
>
> > Is this a known issue / are there workarounds?
>
> Yes, sort of, we've seen it many times with in-process crash handlers.
>
> > If during malloc a crash signal occurs, the jvm will hang because it will
> > call again malloc, which is not reentrant (for explanation see
> >
> https://stackoverflow.com/questions/40049751/malloc-inside-linux-signal-handler-cause-deadlock
> ).
> >
> >
> > This is for production environments a big problem because self-healing
> (in
> > this case an automatic restart through jsvc) will not work. Resulting in
> > manual actions by cloud administrators!
>
> The recommended practice is to use a crash handler external to the
> process.  Of course, this is not going to fix the underlying issue which
> causes the crash.
>
> > #11 0x00007f123a9fbbae in VMError::report_and_die(Thread*, unsigned
> > int, unsigned char*, void*, void*) () from
> > /usr/java/latest/lib/server/libjvm.so
> > #12 0x00007f123a7dea10 in JVM_handle_linux_signal () from
> > /usr/java/latest/lib/server/libjvm.so
> > #13 0x00007f123a7d2c08 in signalHandler(int, siginfo*, void*) () from
> > /usr/java/latest/lib/server/libjvm.so
> > #14 <signal handler called>
> > #15 0x0000003ce2c7856c in _int_malloc () from /lib64/libc.so.6
>
> The question is whether a verbose crash report is actually needed if the
> PC value (as recorded in the siginfo* argument) is within libc.so.6.
> Maybe in this case, a more limited crash dump is appropriate.
>
> Thanks,
> Florian
>

From fweimer at redhat.com  Mon Sep 30 13:47:10 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 30 Sep 2019 15:47:10 +0200
Subject: none
In-Reply-To: <CAO7qondaCJuwUMts4K1TpVBb_Ys2bHGDzwS+h5FVcjh7kwsDoQ@mail.gmail.com>
 (Donald Kwakkel's message of "Mon, 30 Sep 2019 15:34:33 +0200")
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 <87impa2bb0.fsf@oldenburg2.str.redhat.com>
 <CAO7qondaCJuwUMts4K1TpVBb_Ys2bHGDzwS+h5FVcjh7kwsDoQ@mail.gmail.com>
Message-ID: <87sgod28wx.fsf@oldenburg2.str.redhat.com>

* Donald Kwakkel:

> So you mean that if jsvc is not used the hang will not occur? Because
> if I look at the stack I do not see any jsvc related code executed.
> (Indeed I am not looking howto make sure not to crash, but how to make
> sure a crash will not hang).

Sorry, I don't follow.  I didn't mean to imply anything about jsvc.  I
did not know you were using it.

> Is it possible to disable the verbose crash report?

-XX:+SuppressFatalErrorMessage should do that, and a quick test (with
kill -SIGSEGV) confirms that.

Thanks,
Florian

From dkwakkel at gmail.com  Mon Sep 30 13:50:46 2019
From: dkwakkel at gmail.com (Donald Kwakkel)
Date: Mon, 30 Sep 2019 15:50:46 +0200
Subject: none
In-Reply-To: <87sgod28wx.fsf@oldenburg2.str.redhat.com>
References: <CAO7qoncJVD+j8SyehHz1z7sr_AMfeWrp=Q1r3iLGwGF+G3o6WA@mail.gmail.com>
 <87impa2bb0.fsf@oldenburg2.str.redhat.com>
 <CAO7qondaCJuwUMts4K1TpVBb_Ys2bHGDzwS+h5FVcjh7kwsDoQ@mail.gmail.com>
 <87sgod28wx.fsf@oldenburg2.str.redhat.com>
Message-ID: <CAO7qoneJv0B8rbxBiLV_QO0ni_-o2kv+FXZWLvm2hHLrG-KA2g@mail.gmail.com>

Thanks, that was where I was looking for!

Op ma 30 sep. 2019 om 15:47 schreef Florian Weimer <fweimer at redhat.com>:

> * Donald Kwakkel:
>
> > So you mean that if jsvc is not used the hang will not occur? Because
> > if I look at the stack I do not see any jsvc related code executed.
> > (Indeed I am not looking howto make sure not to crash, but how to make
> > sure a crash will not hang).
>
> Sorry, I don't follow.  I didn't mean to imply anything about jsvc.  I
> did not know you were using it.
>
> > Is it possible to disable the verbose crash report?
>
> -XX:+SuppressFatalErrorMessage should do that, and a quick test (with
> kill -SIGSEGV) confirms that.
>
> Thanks,
> Florian
>

From stefan.reich.maker.of.eye at googlemail.com  Mon Sep 30 14:54:18 2019
From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich)
Date: Mon, 30 Sep 2019 16:54:18 +0200
Subject: 100% cpu on arm32 in Service Thread
In-Reply-To: <efd68d48-fed6-a553-1a3a-64ac6de3ff8c@oracle.com>
References: <5BC9C706-F274-4C3D-BCDC-63B2F02CF101@contoso.com>
 <CAC2-jLFppAWRPPag0ZNOtQRGYJa5vMs1o=Hvbt+JrYd4xfRoOg@mail.gmail.com>
 <efd68d48-fed6-a553-1a3a-64ac6de3ff8c@oracle.com>
Message-ID: <CAC2-jLFkNs0AETKy2=x8ZtMWZfN31pKQNSOfQSC_NJ4iVLA_mA@mail.gmail.com>

Hi Thomas,

thanks for your question, I will try if I can. However it's really hard to
reproduce at all, and I am migrating all systems to ZGC...

Yeah, I should upgrade to EA 33 too.


Stefan

On Mon, 30 Sep 2019 at 10:34, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi,
>
> On 27.09.19 18:08, Stefan Reich wrote:
> > Hold on! This might be the same bug I am chasing - and seeing right now
> > again, in fact. This is on Linux with JDK 13 EA 31 and top -H:
> >
> >    PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+
> COMMAND
> >
> > 18690 root      20   0 7750728 3,775g  37660 R 98,2 32,1  12638:21 G1
> > Conc#0
> >
> > This is going on indefinitely as long as the JVM runs.
>
>    can you give more details about the platform (x64?) and program you
> used to reproduce this?
>
> Does it reproduce with jdk13 build 33 (the ga build)?
>
> Thanks,
>    Thomas
>


-- 
Stefan Reich
BotCompany.de // Java-based operating systems