Great, thanks for reviewing Jaroslav and Serguei!
Marcus
On 01/14/2016 08:07 PM, serguei.spit...@oracle.com wrote:
+1 Ship it!
Thanks,
Serguei
On 1/14/16 07:18, Jaroslav Bachorik wrote:
Ship it!
-JB-
On 14.1.2016 16:09, Marcus Larsson wrote:
Hi,
Please review the following patch to add t
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.
Thanks,
Marcus
-Dmitry
On 2016-01-14 18:00, Marcus Larsson wrote:
Hi,
On 15/01/2016 4:59 AM, Martin Buchholz wrote:
The process grim reaper ends up being the first point of failure since
it tries not to waste the user's memory and it's in a core library,
but in principle it's not special. I think a more general workaround
would be to add a hotspot flag that would
Hi Yasumasa,
An enhancement like this requires new tests to go with it.
Thanks,
David
On 15/01/2016 12:00 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> We can use Attach API to attach JVMTI agent to live process.
> However, we have to write Java code for it.
>
> If we can attach JVMTI agents throu
Hi Dmitry,
> Otherwise looks good for me (I'll sponsor the push).
Thanks!
> 1. It's better to check _libpath.value() and write a message, that the
> parameter is required.
I set true to 4th argument (mandatory) of DCmdArgument c'tor.
If we execute jcmd without libpath, we get message as below:
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 automatically, so instead the patch adds an attempt to
> remo
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 own
purging. If you just want a number of generations with a fi
+1 Ship it!
Thanks,
Serguei
On 1/14/16 07:18, Jaroslav Bachorik wrote:
Ship it!
-JB-
On 14.1.2016 16:09, Marcus Larsson wrote:
Hi,
Please review the following patch to add the serviceability/logging
folder to the hotspot_serviceability test group. This will include the
UL tests for JPRT run
The process grim reaper ends up being the first point of failure since
it tries not to waste the user's memory and it's in a core library,
but in principle it's not special. I think a more general workaround
would be to add a hotspot flag that would add a memory safety zone to
all threads. If it'
Hi all,
Could you please review this patch?
Thanks,
Yuji
2015-12-18 15:27 GMT+09:00 KUBOTA Yuji :
> Hi all,
>
> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
> jhsdb as below.
>
> -
> ./jhsdb clhsdb --pid 16809
> Attaching to process 16809, please wait...
> hsdb> cla
> On Jan 14, 2016, at 1:51 AM, Dmitry Samersoff
> wrote:
>
> David,
>
>> Is this because the management API's are actually split across
>> the base module (java.lang.management) and the jdk.management module?
>> If so that seem messy. If not then I'm not understanding the issue.
>
> Yes. Exac
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, serguei.spit...@oracle.com wrote:
> > > > > O
Marcus,
fopen(name, "wa+") truncate file before open it in append mode.
-Dmitry
On 2016-01-14 18:00, 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
Ship it!
-JB-
On 14.1.2016 16:09, Marcus Larsson wrote:
Hi,
Please review the following patch to add the serviceability/logging
folder to the hotspot_serviceability test group. This will include the
UL tests for JPRT runs.
Webrev:
http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/
Issue
Hi,
Please review the following patch to add the serviceability/logging
folder to the hotspot_serviceability test group. This will include the
UL tests for JPRT runs.
Webrev:
http://cr.openjdk.java.net/~mlarsson/8147079/webrev.00/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8147079
Test
Yasumasa,
diagnosticCommand.cpp:294
1. It's better to check _libpath.value() and write a message, that the
parameter is required.
2. It might be better to avoid malloc here by pre-calcualting length of
required option length and than declare
char *new_options[new_options_len];
Otherwise looks
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 automatically, so instead the patch adds an
attempt to remove the log file before opening it.
Webrev:
http://cr.openjdk.java
Daniel,
> OK. What of the sun.* implementation classes in java.management?
> Should these be REQUIRED as well?
java.management module might be missing. It's the main goal to the fix -
provide a way to handle missing java.management module on VM level.
i.e.
if java.lang.management is missing, VM
Hi all,
We can use Attach API to attach JVMTI agent to live process.
However, we have to write Java code for it.
If we can attach JVMTI agents through jcmd, it is very useful.
So I want to add two new diagnostic commands:
* JVMTI.agent_load: Load JVMTI native agent.
* JVMTI.javaagent_load: Loa
On 14/01/2016 12:06, David Holmes wrote:
Of course, but I'm having trouble seeing the overall architecture of
the solution or understanding how the problem manifests. Is it just VM
initialization that assumes classes are always present?
I haven't looked at what Dmitry is doing but I think par
Hi Dmitry,
On 14/01/16 13:31, Dmitry Samersoff wrote:
Daniel,
What strategy did you use to decide whether
to use OPTIONAL | REQUIRED?
I'm not sure I understand the logic...
Everything in java.lang.management should be REQUIRED, anything outside
of it - OPTIONAL.
java_lang_management_MemoryU
Daniel,
> What strategy did you use to decide whether
> to use OPTIONAL | REQUIRED?
> I'm not sure I understand the logic...
Everything in java.lang.management should be REQUIRED, anything outside
of it - OPTIONAL.
java_lang_management_MemoryUsage_klass should be required, it's just a
typeo.
-D
On 14/01/2016 8:46 PM, Alan Bateman wrote:
On 14/01/2016 04:06, David Holmes wrote:
Is this because the management API's are actually split across the
base module (java.lang.management) and the jdk.management module? If
so that seem messy. If not then I'm not understanding the issue.
The two
Hi Dmitry,
First an observation:
- java.lang.management and sun.management packages are part of
the java.management module.
- com.sun.management and com.sun.management.internal are part
of jdk.management
What strategy did you use to decide whether to use OPTIONAL | REQUIRED?
I'm not sure I
On 14/01/2016 04:06, David Holmes wrote:
Is this because the management API's are actually split across the
base module (java.lang.management) and the jdk.management module? If
so that seem messy. If not then I'm not understanding the issue.
The two management modules are:
java.management
On 14/01/2016 7:51 PM, Dmitry Samersoff wrote:
David,
Is this because the management API's are actually split across
the base module (java.lang.management) and the jdk.management module?
If so that seem messy. If not then I'm not understanding the issue.
Yes. Exactly.
Moreover future managem
The fix looks good.
However, it seems, there check at the lines 172 or 218 could be done
before the call to the calloc().
In such a case, there would be no need to free the new_lib.
It can be like this:
if (strlen(libname) >= BUF_SIZE - 1) {
print_debug("libname %s too long\n", libname);
On 14.1.2016 10:47, Dmitry Samersoff wrote:
Everybody,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8145698/webrev.01/
added missed free() call.
Looks good!
Thanks,
-JB-
-Dmitry
David,
> Is this because the management API's are actually split across
> the base module (java.lang.management) and the jdk.management module?
> If so that seem messy. If not then I'm not understanding the issue.
Yes. Exactly.
Moreover future management functionality may require additional modu
Everybody,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8145698/webrev.01/
added missed free() call.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Hi Jaroslav,
Thank you very much for the review.
Best regards,
Alexander
- Original Message -
From: jaroslav.bacho...@oracle.com
To: alexander.kulyakh...@oracle.com, serviceability-dev@openjdk.java.net
Cc: stefan.sa...@oracle.com, staffan.lar...@oracle.com
Sent: Wednesday, January 13, 20
31 matches
Mail list logo
