Hi Mikael,
On 12/15/15 1:56 AM, Mikael Gerdin wrote:
Hi Chris,
sorry for the late reply.
On 2015-12-10 22:31, Chris Plummer wrote:
Hi Mikael,
See comments inline below:
On 12/9/15 8:48 AM, Mikael Gerdin wrote:
On 2015-12-08 20:14, Chris Plummer wrote:
[Adding serviceability-dev@openjdk.ja
On 12/15/15 3:04 PM, Alex Henrie wrote:
2015-12-15 14:56 GMT-07:00 Daniel D. Daugherty :
The following bug was filed to track this issue:
JDK-8145278 Memory leak in splitPathList
https://bugs.openjdk.java.net/browse/JDK-8145278
I added a comment to that bug report and it turns out
that Dmitry
2015-12-15 14:56 GMT-07:00 Daniel D. Daugherty :
> The following bug was filed to track this issue:
>
> JDK-8145278 Memory leak in splitPathList
> https://bugs.openjdk.java.net/browse/JDK-8145278
>
> I added a comment to that bug report and it turns out
> that Dmitry had a similar comment back in N
Alex,
The following bug was filed to track this issue:
JDK-8145278 Memory leak in splitPathList
https://bugs.openjdk.java.net/browse/JDK-8145278
I added a comment to that bug report and it turns out
that Dmitry had a similar comment back in November...
The discussion need to move from the mail
# HG changeset patch
# User Alex Henrie
# Date 1447827030 25200
# Tue Nov 17 23:10:30 2015 -0700
# Node ID 6dca8affef8a4566dfaa36faeb7a14fc4086843a
# Parent dc90094c0d66b3df2944da215d93542507c31e60
Skip the null pointer check before calling realloc.
"If ptr is a null pointer, realloc() shal
Hi,
Thanks for the comments, David.
I had messed up my uploading before and had not actually updated the
open html. So for real this time, the most recent webrev is at
http://cr.openjdk.java.net/~rprotacio/8141211.01/ Of note:
- each incident of ttyLocker that involved separate logging lines f
Hi,
Please review the following changes for task "JDK-8058865 : JMX Test
Refactoring"
Issue: https://bugs.openjdk.java.net/browse/JDK-8058865
Webrev: http://cr.openjdk.java.net/~olagneau/8058865/webrev.06/
Issue Description:
" The majority of the JMX related tests are in JTreg. There is a sma
On 2015-12-15 16:13, Markus Gronlund wrote:
Looks good, thanks again for doing all of this.
Great, thanks for reviewing!
Marcus
I will be quiet now :-)
/Markus
-Original Message-
From: Marcus Larsson
Sent: den 15 december 2015 16:13
To: Markus Gronlund
Cc: hotspot-runtime-...@ope
Looks good, thanks again for doing all of this.
I will be quiet now :-)
/Markus
-Original Message-
From: Marcus Larsson
Sent: den 15 december 2015 16:13
To: Markus Gronlund
Cc: hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: RFR: 8145083: Use semap
Hey Markus,
On 2015-12-15 11:58, Markus Gronlund wrote:
Hi Marcus,
Looks good!
One minor thing that you don't need to fix if you don't want to:
I would use:
class ConfigurationLock {
...
debug_only(static bool current_thread_has_lock();)
};
to declare the this function in the class, th
On 2015-12-14 17:55, Jaroslav Bachorik wrote:
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
The problem is that the class UsageTrackerClient is accessing
RuntimeMXBean.getInputArgumen
while(true) would convey that much more clearly - and perhaps obviate
the need for pr_ex.
Yes, I can surely transform the code
- while (pr_ex != curr_id) {
+ if (pr_ex != curr_id) {
+ while (true} {
The intention was to save a line :-)
I'll use while (true), if it imp
Chris,
1. Please file a separate CR for SA (assign it to me) and go ahead with
your fix when it become ready.
2. As far as I understand the fix, you just removed explicit alignment
for all platforms (not only 32bit) and rely on compiler. I'm a bit
scared with it (see David's comments).
Also plea
On 15/12/2015 10:00 PM, Ivan Gerasimov wrote:
On 15.12.2015 9:31, David Holmes wrote:
I really wish we had some view inside windows to see exactly what is
going wrong here. :(
Yes, so do I!
It would be really helpful to know exactly how this race bug is
"implemented".
Or, at least, how to d
On 15.12.2015 9:31, David Holmes wrote:
I really wish we had some view inside windows to see exactly what is
going wrong here. :(
Yes, so do I!
It would be really helpful to know exactly how this race bug is
"implemented".
Or, at least, how to deal with it to avoid the return code replacem
Hi Marcus,
Looks good!
One minor thing that you don't need to fix if you don't want to:
I would use:
class ConfigurationLock {
...
debug_only(static bool current_thread_has_lock();)
};
to declare the this function in the class, then I would move the definition
outside of it (since it's si
Hi,
New webrev:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.03/
Incremental:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02-03/
ConfigurationLocker renamed to ConfigurationLock to avoid confusion with
the MutexLocker family of classes.
Semaphore and locking thread id moved into
Hi Chris,
sorry for the late reply.
On 2015-12-10 22:31, Chris Plummer wrote:
Hi Mikael,
See comments inline below:
On 12/9/15 8:48 AM, Mikael Gerdin wrote:
On 2015-12-08 20:14, Chris Plummer wrote:
[Adding serviceability-dev@openjdk.java.net]
Hi Mikael,
Thanks for pointing this out. I'll
Hi Markus,
On 2015-12-14 21:53, Markus Gronlund wrote:
Hi Marcus,
Thanks for updating the patch.
I think you could also move the lock representation, i.e the Semaphore to
become a (static) field inside the ConfigurationLocker class - this since you
want all entry/exits to go through instance
Build changes look good to me.
/Erik
On 2015-12-14 17:55, Jaroslav Bachorik wrote:
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
The problem is that the class UsageTrackerClient is a
Hi Kim,
On 2015-12-15 02:17, Kim Barrett wrote:
On Dec 14, 2015, at 9:53 AM, Marcus Larsson wrote:
Hi,
New webrev:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/
Incremental:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/
One minor nit:
Yuji,
I'll take a look.
-Dmitry
On 2015-12-15 11:23, KUBOTA Yuji wrote:
> Hi all,
>
> When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
> not terminate after throwing HeadlessException.
>
> HSDB starts WorkerThread before making the JFrame. If we run HSDB on
> CLI, HSDB thro
Hi all,
When I ran HSDB by jhsdb on CLI i.e. without x11 display, HSDB could
not terminate after throwing HeadlessException.
HSDB starts WorkerThread before making the JFrame. If we run HSDB on
CLI, HSDB throws HeadlessException when makes the JFrame. Thus, the
WorkerThread has never shutdown, th
On 15.12.2015 08:03, Alan Bateman wrote:
On 14/12/2015 16:55, Jaroslav Bachorik wrote:
Please, review the following change
Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
The problem is that the class UsageTrackerClient
Hi Harsha,
The fix looks good in general.
If I understand correctly, any invoke of the requestList().add(),
requestList().remove()
or requestList().clear() will be implicitly synchronized on the list object.
There only place left where we still need an explicit synchronized statement
is the it
25 matches
Mail list logo
