Looks fine.
Naoto
On 10/26/17 11:24 PM, Rachna Goel wrote:
Hi,
Kindly review the fix to JDK-8185841.
Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.
patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/
Fix is to relocate this region dependent data. New Bundle will be
+1
On 10/27/17 5:39 PM, mandy chung wrote:
On 10/27/17 2:37 PM, Brent Christian wrote:
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a
private
constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new
On 10/27/17 2:37 PM, Brent Christian wrote:
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a private
constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new webrev:
On 10/27/2017 11:19 AM, mandy chung wrote:
It may be cleaner to initialize the map in a single place e.g. a private
constructor taking Properties and initialCapacity.
Yeah, that's a good idea. See new webrev:
http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html
Thanks,
-Brent
Hi All,
I’m very confused about what was intended with the ‘UNORDERED’ Collector
characteristic. My logical inference was that unordered as a Collector
characteristic meant that the result of this collector applied to any stream
was independent of the order of element delivery. This means
serviceability-dev is the mailing list for discussing
java.lang.management APIs.
Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids)
does not get the stack trace and locks information and is less expensive.
A typical lightweight monitoring application does BCI and call
I completely missed the fact that Properties continues to inherit from
Hashtable but the data is actually stored in a CHM. I would have been
afraid to make that change ...
Looks good!
On Thu, Oct 26, 2017 at 6:43 PM, Brent Christian wrote:
> Hi,
>
> It would be
Hi,
(A bit too quick on the send button; need to reallocate if the array is
not big enough).
I was just pointing out there already is access to the information you
are requesting
without adding a new API.
ThreadGroup.activeCount() provides the number of active threads.
Of course, threads
Hi,
I was just pointing out there already is access to the information you
are requesting
without adding a new API.
ThreadGroup.activeCount() provides the number of active threads.
Of course, threads come and go asynchronously.
Yes, the Thread array has to be allocated by the caller and may
On 10/26/17 6:43 PM, Brent Christian wrote:
Hi,
It would be useful to have a Properties constructor that takes an
argument to set the initial capacity. Such a constructor is present on
many of the other Map implementations in the JDK, including Hashtable,
the superclass of Properties.
In
Hello Remi, Sundar and others,
Please review the webrev [1] to update JDK's internal ASM to v6.
To help with review areas, you can use the browser to search for mq
patches commented with //
Highlights of changes:
1. updated ASMv6 // jdk-new-asmv6.patch
2. changes to jlink and jar to add
Hi Roger,
> You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
> the parents to the root ThreadGroup.
Thanks. Isn't this method silently dropping threads in case it can't hold what
you specified upfront as an array? Apart from that: Would it be a candidate for
Hi Christoph,
You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
the parents to the root ThreadGroup.
$.02, Roger
On 10/27/2017 11:23 AM, Christoph Dreis wrote:
Hey,
I don't know if this is the correct mailing list for this specific topic.
Please let me know in case
Hey,
I don't know if this is the correct mailing list for this specific topic.
Please let me know in case it isn't.
I'm currently trying to improve the live-monitoring of an application and
would like to get a simple overview of how many threads are in state
RUNNABLE, BLOCKED and so on.
For this
Hi Alan,
Thank you for your review and comments.
I updated webrev based on your comments:
http://cr.openjdk.java.net/~horii/8188858/webrev.05/
Alan Bateman wrote on 2017/10/26 19:31:53:
> I've read through webrev.03 and webrev.04 and they seem correct. Are
> there
Hi Martin,
Thank you very much for the heads-up. I have filed a bug for the same:
https://bugs.openjdk.java.net/browse/JDK-8190259
Thank you for the patch as well. This will be integrated into JDK along with
the tzdata2017c.
Regards,
Ramanand.
From: Martin Buchholz
Hi,
Kindly review the fix to JDK-8185841.
Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.
patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/
Fix is to relocate this region dependent data. New Bundle will be
generated when Locale id has non empty script and country code
17 matches
Mail list logo