RFR 8220570: Additonal trace when native thread creation fails

[Lindenmaier, Goetz]

Hi Ralf, 

I appreciate your extension. 
Especially I like you are printing the container limits.
While your first printout actually is very verbose, I think the 
second is too short.

I would print something like this:
"
[19.430s][warning][os,thread] Nr of threads approx. running in the VM: 9555 
[19.431s][warning][os,thread] system-wide limit on the number of threads (/proc/sys/kernel/threads-max): 127667 
[19.431s][warning][os,thread] maximum number of memory map areas a process may have (/proc/sys/vm/max_map_count): 65530 
[19.431s][warning][os,thread] system-wide limit on number of process identifiers (/proc/sys/kernel/pid_max): 131072
[19.431s][warning][os,thread] address space limit 1000M, proc mem limit 5118M, stack limit 900k
"

@ David,
while this are mostly system values that don't change, I would consider 
the number of running threads a value from the VM definitely important for
this warning as it can not be obtained later on at all.
If the other information is printed on a different log level, the number
of current threads still should go to "warning".
Maybe it can be added to the first line.

Best regards,
  Goetz.


> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-
> bounces at openjdk.java.net> On Behalf Of Schmelter, Ralf
> Sent: Montag, 18. März 2019 11:11
> To: David Holmes <david.holmes at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: [CAUTION] RE: RFR 8220570: Additonal trace when native thread
> creation fails
> 
> 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
> >