RFR 8220570: Additonal trace when native thread creation fails

[David Holmes]

Hi Ralf,

On 18/03/2019 8:11 pm, Schmelter, Ralf wrote:
> 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) ?

So basically you've just selected subsets of the rlimit and memory 
output and put everything on one line. And in doing that you've had to 
duplicate the os_posix.cpp logic for getting the various rlimits.

So this doesn't generally reduce the volume of output in the general 
case, and it causes code duplication (though perhaps by the time you 
implement this for the other platforms it will get refactored into 
os_posix again?)

I'm still not at all convinced this level of detail is appropriate for 
"warning" level logging.

Sorry.

David
-----



> 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
>>