RFR: 8267209: Child threads should defer logging to after child-parent handshake

David Holmes david.holmes at oracle.com
Mon May 17 00:54:24 UTC 2021


Sorry I read things too quickly ...

On 17/05/2021 8:54 am, David Holmes wrote:
> On Sun, 16 May 2021 06:57:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>> Hi,
>>
>> May I have reviews for this very simple change (triggered by this ML discussion [1]):
>>
>> On Linux and BSD, we have a handshake between creator thread and newborn thread. Creator thread waits until the newborn is alive and reports back via a monitor handshake.
>>
>> The newborn should avoid doing anything unnecessary before reporting back to the creator. But we added logging there, whose performance impact can be anything. We should defer logging to after that handshake.
>>
>> I ran OPs [1] test on my machine and with logging to a very fast ssd enabled:
>>
>>
>> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest
>> Duration: 5191
>>
>>
>> with this patch test time drops by about 19%:
>>
>>
>> thomas at starfish:/shared/projects/openjdk$ ./jdk-jdk/output-release/images-stock/jdk/bin/java -Xlog:os+thread:t1.log -cp ./test/repros/repros8/target/repros8-1.0.jar de.stuefe.repros.WaishonTest
>> Duration: 4228
>>
>>
>> No perceptible difference with logging disabled, as it should be.
>>
>> ---
>>
>> (Side note: We don't do this handshake on AIX and Windows. Instead, there, we create the thread in suspended state and resume it later. Would be nice to get rid of that handshake for Linux too.)
>>
>> [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005807.html
> 
> Hi Thomas,
> 
> This change seems okay. Arguably if we were trying to track down a problem with the initial "handshake" then we may want logging on each side of that handshake. Also logging is supposed to be nearly free if not enabled so I'm disappointed to find this causes a noticeable difference. :(

Misread the problem. I thought the logging was an issue even when 
disabled. With it enabled I don't really care if it causes a lag in the 
handshake. To me this is not an issue.

David

> As Linux/BSD/macOS can't start threads suspended we have to emulate that with this handshake. The reason this is/was needed is to ensure the newly created thread can't run to completion and delete itself before the creator has finished the initial interaction with it.
> 
> Cheers,
> David
> 
> -------------
> 
> Marked as reviewed by dholmes (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4042
> 


More information about the hotspot-runtime-dev mailing list