Hi David and Robbin,
Thank you for reviewing this fix!
Best regards,
Daniil
On 10/8/19, 1:49 AM, "Robbin Ehn" wrote:
Great, thanks!
/Robbin
On 2019-10-07 18:41, Daniil Titov wrote:
> Hi Robbin,
>
> Yes, I ran my benchmark [1]. Please see below the output sho
Great, thanks!
/Robbin
On 2019-10-07 18:41, Daniil Titov wrote:
Hi Robbin,
Yes, I ran my benchmark [1]. Please see below the output showing that the table
was grown.
../jdk/build/linux-x64-release/images/jdk/bin/java -cp .
-Xlog:thread+table=info ThreadStartupTest
Starting the test
[0.185s]
Hi Robbin,
Yes, I ran my benchmark [1]. Please see below the output showing that the table
was grown.
../jdk/build/linux-x64-release/images/jdk/bin/java -cp .
-Xlog:thread+table=info ThreadStartupTest
Starting the test
[0.185s][info][thread,table] Grown to size:512
The test finished.
Execution
Hi Daniil,
Yes, good, but:
>> Testing: Mach5 tier1, tier2, and tier3 tests successfully passed.
And if you have not done so, you should test this with the benchmark you
have as
a stress test and see that this does what we think.
Can you please test it with your benchmark, if
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 ThreadIdTable
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, "Thread
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 fo
Hi Daniil,
On 4/10/2019 1:38 pm, Daniil Titov wrote:
Hi David and Robbin,
Please review a new version of the fix that makes the service thread
responsible for the thread table growth.
Webrev: http://cr.openjdk.java.net/~dtitov/8231666/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-
Hi David and Robbin,
Please review a new version of the fix that makes the service thread
responsible for the thread table growth.
Webrev: http://cr.openjdk.java.net/~dtitov/8231666/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8231666
Testing: Mach5 tier1, tier2, and tier3 tests
Hi Daniil,
On 3/10/2019 2:21 am, Daniil Titov wrote:
Hi David and Robbin,
Could we consider making the ServiceThread responsible for the ThreadIdTable
resizing in the similar way how
it works for StringTable and ResolvedMethodTable, rather than having
ThreadIdTable::add() method calling Th
Hi Daniil,
On 2019-10-02 18:21, Daniil Titov wrote:
Hi David and Robbin,
Could we consider making the ServiceThread responsible for the ThreadIdTable
resizing in the similar way how
it works for StringTable and ResolvedMethodTable, rather than having
ThreadIdTable::add() method calling Thr
Hi David,
On 2019-10-02 15:25, David Holmes wrote:
Hi Robbin,
On 2/10/2019 7:58 pm, Robbin Ehn wrote:
Hi David,
What if the table is full and must be grown?
The table uses chaining, it just means load factor tip over what is considered
a good backing array size.
Coleen raised a good que
Hi David and Robbin,
Could we consider making the ServiceThread responsible for the ThreadIdTable
resizing in the similar way how
it works for StringTable and ResolvedMethodTable, rather than having
ThreadIdTable::add() method calling ThreadIdTable::grow()?
As I understand It should solve t
Hi Robbin,
On 2/10/2019 7:58 pm, Robbin Ehn wrote:
Hi David,
What if the table is full and must be grown?
The table uses chaining, it just means load factor tip over what is
considered a good backing array size.
Coleen raised a good question in a separate discussion, which made me
realiz
Hi David,
What if the table is full and must be grown?
The table uses chaining, it just means load factor tip over what is considered a
good backing array size.
That aside, I'd like to know how expensive it is to grow this table. What are we
talking about here?
We use global counter whic
On 2/10/2019 7:15 pm, Robbin Ehn wrote:
Hi, since holding the Threads_lock while growing can block out
safepoints for a
longer period, I would suggest just skip growing when holding Threads_lock.
E.g. return before creating the GrowTask.
What if the table is full and must be grown?
That aside
Hi, since holding the Threads_lock while growing can block out safepoints for a
longer period, I would suggest just skip growing when holding Threads_lock.
E.g. return before creating the GrowTask.
/Robbin
On 2019-10-02 08:46, David Holmes wrote:
Hi Daniil,
On 2/10/2019 4:13 pm, Daniil Titov w
Hi Daniil,
On 2/10/2019 4:13 pm, Daniil Titov wrote:
Please review a change that fixes the issue. The problem here is that that the
thread is added to the ThreadIdTable (introduced in [3]) while the
Threads_lock is held by
JVM_StartThread. When new thread is added to the thread table the tab
Please review a change that fixes the issue. The problem here is that that the
thread is added to the ThreadIdTable (introduced in [3]) while the
Threads_lock is held by
JVM_StartThread. When new thread is added to the thread table the table checks
if its load factor is greater than required
19 matches
Mail list logo
