Hi Daniil,
On 5/10/2019 1:23 pm, Daniil Titov wrote:
Hi David and Robbin,
Please review a new version of the fix that adds the max size check
check_concurrent_work code [1].
That change seems fine.
I don't think you need to repeat the load factor check here:
void
Hi David and Robbin,
Please review a new version of the fix that adds the max size check
check_concurrent_work code [1].
>I don't think you need to repeat the load factor check here:
>
>void ThreadIdTable::do_concurrent_work(JavaThread* jt) {
> assert(_is_initialized,
Hi Dan,
Thanks for the second look.
On 5/10/2019 1:51 am, Daniel D. Daugherty wrote:
On 10/3/19 11:58 PM, David Holmes wrote:
Okay, to allow for me to make forward progress here I've decided to
follow the "principle of least brokenness" ;-)
Recap: Because of JVMTI event callbacks it is
On 10/3/19 11:58 PM, David Holmes wrote:
Okay, to allow for me to make forward progress here I've decided to
follow the "principle of least brokenness" ;-)
Recap: Because of JVMTI event callbacks it is possible for a thread to
set its current pending monitor as a JvmtiRawMonitor when it was
On 10/3/19 9:55 PM, David Holmes wrote:
On 4/10/2019 10:01 am, Daniel D. Daugherty wrote:
On 10/3/19 7:35 PM, serguei.spit...@oracle.com wrote:
If I remember correctly it is a scenario where this issue also
comes to the picture:
https://bugs.openjdk.java.net/browse/JDK-8033399
I do not
Hi Daniil,
You might also want to put the max size check in the check_concurrent_work code:
+ // Resize if we have more items than preferred load factor
+ if ( load_factor > PREF_AVG_LIST_LEN &&
!_local_table->is_max_size_reached()) {
so that we don't keep waking up the service thread
