Re: RFR: 8146879: Truncate new UL log files

Hi Dmitry, On 01/15/2016 08:52 AM, Marcus Larsson wrote: On 01/14/2016 04:28 PM, Dmitry Samersoff wrote: Marcus, fopen(name, "wa+") truncate file before open it in append mode. Ah, didn't know you could do that. If it works that would be much better, I'll give it a shot. Unfortunately

Re: RFR: 8146879: Truncate new UL log files

I will second what others have already said. I do not think the existing logs should be removed (even if this has been the case before). A quite likely scenario is that when a critical application hangs, crash or misbehaves, a quick restart is done. After the service is up again, the

Re: RFR: 8146879: Truncate new UL log files

Hi, On 01/15/2016 02:15 PM, Stefan Särne wrote: I will second what others have already said. I do not think the existing logs should be removed (even if this has been the case before). A quite likely scenario is that when a critical application hangs, crash or misbehaves, a quick restart

Re: RFR(M): JDK-8141070 vm/services/management.cpp should be resilient to missing 'jdk.management' module

Hi Dmitry, This is still not clear to me why java.lang.management and sun.management are handled differently - since they are in the same module. best regards -- daniel On 14/01/16 15:49, Dmitry Samersoff wrote: Daniel, >OK. What of the sun.* implementation classes in java.management?

Re: RFR: 8146879: Truncate new UL log files

Marcus, > Unfortunately this doesn't work on all platforms. > Windows fails to open > files in this mode, so I'm guessing > it's some GCC extension we can't use. If my memory is not bogus, the same effect under windows could be achieved by: int fd = _open("filename", _O_RDWR | _O_APPEND |

Re: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

Hi, I added permissions and tests in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8147388/webrev.01/ Two tests (LoadAgentDcmdTest, LoadJavaAgentDcmdTest) work fine. Thanks, Yasumasa On 2016/01/15 17:20, Staffan Larsen wrote: This is a good improvement overall. The new

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

Hi, If just doubling the size of the Reaper stack would suffice, I would start there. If a mechanism (property) is needed to make an adjustment to the stack size, then I'd prefer something that applied to all Threads, not just the reaper. It can be done in the Java code in Thread and would be

Re: RFR(xs): 8147442: Event-based tracing to allow for tracing Klass creation

Looks good! Erik On 2016-01-15 10:52, Markus Gronlund wrote: Greetings, Please review this small change in order to allow for the Event-based tracing framework to trace the creation of Klass’es. Bug: https://bugs.openjdk.java.net/browse/JDK-8147442 Webrev:

Re: RFR: 8146879: Truncate new UL log files

On 1/15/16 05:15, Stefan Särne wrote: I will second what others have already said. I do not think the existing logs should be removed (even if this has been the case before). A quite likely scenario is that when a critical application hangs, crash or misbehaves, a quick restart is done.

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 14.1.2016 17:23, Severin Gehwolf wrote: Hi, On Wed, 2016-01-13 at 10:51 -0800, serguei.spit...@oracle.com wrote: > On 1/13/16 03:16, Jaroslav Bachorik wrote: >> On 12.1.2016 12:55, serguei.spit...@oracle.com wrote: >>> On 1/12/16 03:49, Jaroslav Bachorik wrote: On 12.1.2016 11:47,

Re: RFR: JDK-8147388: Add diagnostic commands to attach JVMTI agent.

This is a good improvement overall. The new diagnostic commands need to have proper permissions set: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", “control", NULL}; return p; } And as David

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

Hi, On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: > > Sorry for being late in the game with this. > > > > +private static List getAddressesForLocalHost() { > > + > >   try { > > -addrs = InetAddress.getAllByName("localhost"); > > -} catch

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On 15.1.2016 10:24, Severin Gehwolf wrote: Hi, On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: Sorry for being late in the game with this. +private static List getAddressesForLocalHost() { + try { -addrs = InetAddress.getAllByName("localhost"); -

Re: RFR: 8146879: Truncate new UL log files

On 2016-01-14 23:43, Kim Barrett wrote: On Jan 14, 2016, at 10:00 AM, Marcus Larsson wrote: Hi, Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done

Re: jmx-dev [ding] Re: [pong] Re: [ping] Re: RFR 8146015: JMXInterfaceBindingTest is failing intermittently for IPv6 addresses

On Fri, 2016-01-15 at 10:28 +0100, Jaroslav Bachorik wrote: > On 15.1.2016 10:24, Severin Gehwolf wrote: > > Hi, > > > > On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote: > > > > Sorry for being late in the game with this. > > > > > > > > +private static List

RFR(xs): 8147442: Event-based tracing to allow for tracing Klass creation

Greetings, Please review this small change in order to allow for the Event-based tracing framework to trace the creation of Klass'es. Bug: https://bugs.openjdk.java.net/browse/JDK-8147442 Webrev: http://cr.openjdk.java.net/~mgronlun/8147442/webrev01/ Thanks Markus

Re: RFR: 8146879: Truncate new UL log files

Hi, On 01/14/2016 09:36 PM, e...@zusammenkunft.net wrote: Hello, Especially for the GC log it is bad if the file is lost after a restart. It is of course possible to include PID or timestamp into the logfile, and then the truncation is no option, however if you do that you have to do your

Re: RFR: 8146879: Truncate new UL log files

Marcus, Generally speaking (out of scope of this changes) 1. Appending (i.e. seek before write) isn't free 2. I'm against of overwriting the log on restart. So personally, I would prefer: a) Have a /signal/DCMD/linecount threshold/ that cause VM to close existing log file and start new one