RFR 8220570: Additonal trace when native thread creation fails

[Schmelter, Ralf]

Hi David,

I've now implemented a Linux version which only tries to print limits which could be the cause for failing to create the thread. It is only one line long. An example output is this:

[0.177s][warning][os,thread] VM has ~3 threads  (limits 127667 global, 131072 pids, 10000 for user), address space limit 1000M, proc mem limit 5118M, stack limit 900k

This was from a shell which had address, data, stack and process limits set. Would this be acceptable (if implemented for the other operation systems too) ?

New webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8220570/webrev.1/

Best regards,
Ralf

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Donnerstag, 14. März 2019 02:20
To: Schmelter, Ralf <ralf.schmelter at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR 8220570: Additonal trace when native thread creation fails

Hi Ralf,

On 13/03/2019 10:17 pm, Schmelter, Ralf wrote:
> Hi,
> 
> I've added additional trace in case an OS thread could not be created. Depending on the OS, not being able to create a thread could have many reasons. On Windows for example it should only be the result of not having enough memory, but on Linux it could be hitting other limits in addition. In order to keep the additional code needed small, I've would reuse methods already used in printing the limits to a hs_err* file, so it includes some which have no relevance for the failure (see the example in the bug report). But given the low occurrence of this errors, I think it should be OK.
> 
> webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8220570/webrev.0/
> bugreport: https://bugs.openjdk.java.net/browse/JDK-8220570

I don't think it appropriate to add all that extra information dump at 
the "warning" level. Either it needs to be significantly reduced, or 
else moved to a lower level. Basic logging is not intended to suffice 
for remote support - YMMV.

Thanks,
David
-----


> Best regards,
> Ralf Schmelter
>