Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
Vladimir, What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? -Konstantin On 28.05.2015 21:22, Vladimir Ivanov wrote: Got it, thanks. Can we ignore errors caused by code cache overflow for now? Best regards, Vladimir Ivanov On 5/28/15 12:03 PM, Konstantin Shefov wrote: Vladimir, This fix is not for timeout issue, this fix is for java.lang.VirtualMachineError: out of space in CodeCache for adapters. Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug. By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed. -Konstantin On 27.05.2015 19:54, Vladimir Ivanov wrote: Have you tried to reduce iteration granularity? Probably, checking execution duration on every test case is more robust. Best regards, Vladimir Ivanov On 5/27/15 5:50 PM, Konstantin Shefov wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. -sherman On 5/29/2015 12:04 AM, Alan Bateman wrote: On 29/05/2015 07:58, Xueming Shen wrote: Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract. -Alan
RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 Thanks, -Sherman
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
On 29/05/2015 07:58, Xueming Shen wrote: Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract. -Alan
Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException VirtualMachineError? Are there other manifestations of the problem? Best regards, Vladimir Ivanov On 28.05.2015 21:22, Vladimir Ivanov wrote: Got it, thanks. Can we ignore errors caused by code cache overflow for now? Best regards, Vladimir Ivanov On 5/28/15 12:03 PM, Konstantin Shefov wrote: Vladimir, This fix is not for timeout issue, this fix is for java.lang.VirtualMachineError: out of space in CodeCache for adapters. Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug. By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed. -Konstantin On 27.05.2015 19:54, Vladimir Ivanov wrote: Have you tried to reduce iteration granularity? Probably, checking execution duration on every test case is more robust. Best regards, Vladimir Ivanov On 5/27/15 5:50 PM, Konstantin Shefov wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin
[8u-dev] Review request : JDK-8081479: Backport JDBC tests from JDK 9 from test/java/sql and test/javax/sql to JDK 8u.
Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8081479 Webrev is http://cr.openjdk.java.net/~kshefov/8081479/webrev.00/ It's a backport of JDK9 JDBC tests to JDK8u. Thanks Maxim
Re: RFR [9] 8080502: Changing accessing module resources
On 26/05/2015 13:24, Miroslav Kos wrote: Thanks, you are correct. Changed to try-catch with resources, the some code moved to SchemaCache. Refernced resources found by com.sun.tools.internal.xjc.SchemaCache.ResourceResolver added to collection and closed after parsing. updated webrev: http://cr.openjdk.java.net/~mkos/8080502/jaxws.02/ tests: rerun standalone tests for bot standalone build and for JDK. This looks much better, it seems to close all the streams now. There's a TODO-Miran left in MetroConfigLoader that I assume should be looked at before you push. In ParserContext then you could throw InternalError(e) rather than e.getMessage(), assuming of course this doesn't need to compile on JDK 7 or older. -Alan
Re: [8u-dev] Review request : JDK-8081479: Backport JDBC tests from JDK 9 from test/java/sql and test/javax/sql to JDK 8u.
Hi Maxim, this looks fine Best Lance On May 29, 2015, at 7:34 AM, Maxim Soloviev maxim.solov...@oracle.com wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8081479 Webrev is http://cr.openjdk.java.net/~kshefov/8081479/webrev.00/ It's a backport of JDK9 JDBC tests to JDK8u. Thanks Maxim Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: JEP 132: More-prompt finalization
Hi Peter,
It is a very interesting proposal but to further David’s comments, the
life-cycle costs of reference objects is horrendous of which the actual process
of finalizing an object is only a fraction of that total cost. Unfortunately
your micro-benchmark only focuses on one aspect of that cost. In other words,
it isn’t very representative of a real concern. In the real world the finalizer
*must compete with mutator threads and since F-J is an “all threads on deck”
implementation, it doesn’t play well with others. It creates a “tragedy of the
commons”. That is situations where everyone behaves rationally with a common
resource but to the detriment of the whole group”. In short, parallelizing
(F-Jing) *everything* in an application is simply not a good idea. We do not
live in an infinite compute environment which means to have to consider the
impact of our actions to the entire group.
This was one of the points of my recent article in Java Magazine which I wrote
to try to counter some of the rhetoric I was hearing in conference about the
universal benefits of being able easily parallelize streams in Java 8. Yes, I
agree it’s a great feature but it must be used with discretion. Case in point.
After I finished writing the article, I started running into a couple of early
adopters that had swallowed the parallel message whole indiscriminately
parallelizing all of their streams. As you can imagine, they were quite
surprised by the results and quickly worked to de-parallelize *all* of the
streams in the application.
To add some ability to parallelize the handling of reference objects seems like
a good idea if you are collecting large numbers of reference objects (10,000
per GC cycle). However if you are collecting large numbers of reference objects
you’re most likely doing something else wrong. IME, finalization is extremely
useful but really only for a limited number of use cases and none of them (to
date) have resulted in the app burning through 1000s of final objects / sec.
It would be interesting to know why why you picked on this particular issue.
Kind regards,
Kirk
On May 29, 2015, at 5:18 AM, David Holmes david.hol...@oracle.com wrote:
Hi Peter,
I guess I'm very concerned about the premise that finalization should scale
to millions of objects and be performed highly concurrently. To me that's
sending the wrong message about finalization. It also isn't the most
effective use of cpu resources - most people would want to do useful work on
most cpu's most of the time.
Cheers,
David
On 29/05/2015 3:12 AM, Peter Levart wrote:
Hi,
Did you know that the following simple loop:
public class FinalizableBottleneck {
static boolean no;
@Override
protected void finalize() throws Throwable {
// empty finalize() method does not make the object finalizable
// (it is not even registered on the finalizer's list)
if (no) {
throw new AssertionError();
}
}
public static void main(String[] args) {
while (true) {
new FinalizableBottleneck();
}
}
}
...quickly fills the entire heap with FinalizableBottleneck and internal
Finalizer objects and brings the JVM to a halt? After a few seconds of
running the above program, jmap -histo:live reports:
num #instances #bytes class name
--
1: 50048325 2001933000 java.lang.ref.Finalizer
2: 50048278 800772448 FinalizableBottleneck
There are a couple of bottlenecks that make this happen:
- ReferenceHandler thread synchronizes with VM to unhook Reference(s)
from the pending chain one be one and dispatches them to their respected
ReferenceQueue(s) which also use synchronization for equeueing each
Reference.
- Enqueueing synchronizes with the finalization thread which removes the
Finalizer(s) (FinalReferences) from the finalization queue and executes
them.
- Executing the Finalizer(s) removes them from the doubly-linked list of
all Finalizer(s) which is used to retain them until they are needed and
this synchronizes with the threads that link new Finalizer(s) into the
doubly-linked list as new finalizable objects get registered.
We see that the creation of a finalizable object only takes one
synchronization (registering into the doubly-linked list) and is
performed synchronously, while finalization takes 4 synchronizations
among 4 different threads (in pairs) and happens when the Finalizer
instance travels over from VM thread to ReferenceHandler thread and
then to finalization thread. No wonder that finalization can not keep up
with allocation in a single thread. The situation is even worse when
finalize() methods do some actual work.
I have experimented with various approaches to widen these bottlenecks
and found out that I can not beat the ForkJoinPool when combined with
some improvements to
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
On 05/29/2015 12:20 AM, Xueming Shen wrote: It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. Perhaps better to merge it now rather than separately? Mandy -sherman On 5/29/2015 12:04 AM, Alan Bateman wrote: On 29/05/2015 07:58, Xueming Shen wrote: Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract. -Alan
Re: RFR 8081027: Create a common test to check adequacy of initial size of static HashMap/ArrayList fields
Thank you Martin for review! On 29.05.2015 3:03, Martin Buchholz wrote: Approved. On Thu, May 28, 2015 at 3:43 PM, Ivan Gerasimov ivan.gerasi...@oracle.com mailto:ivan.gerasi...@oracle.com wrote: Good naming is one of the most difficult part of coding IMO. The chosen names were meant to be read literally: optimal capacity of ArrayList, etc. I agree, 'assert' would tell more about these methods' intention, but I'm not sure how to include it in the names. Maybe rename the class to AssertOptimalCapacity? Assertions are a class of names we are used to importing statically. Junit and Testng both have collections of static methods named assertXXX. For ArrayLists, I would have been happy enough just testing that we have 100% utilization, i.e. size of array is the same as size of the List, without checking the initial capacity. But then the test wouldn't have caught the bug in src/java.base/share/classes/sun/security/ssl/ExtensionType.java The ArrayList was pre-sized to 9, and after reallocation the capacity happened to become (9 + 9/2) = 13, which by coincidence is the final size of the List. It's a tradeoff of maintenance burden vs performance. Note also that oversize is a much bigger performance bug than undersize because you pay for it for the entire process, not just startup.
Re: Why isn't Object.notify() a synchronized method?
Thanks for your hint David. That's the only reason I could imagine too. Can somebody tell something about the cost for recursive lock acquisition in comparison to the whole call, couldn't it be eliminated by Hotspot? As I recently fell into the trap of forgetting the synchronized block around a single notifyAll(), I believe, the current situation is just errorprone. Any comments about the Javadoc issue? -Ulf Am 28.05.2015 um 18:27 schrieb David M. Lloyd: Since most of the time you have to hold the lock anyway for other reasons, I think this would generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why they don't have the synchronized modifier out of the box in Object class. Also I think, the following note should be moved from wait(long,int) to wait(long): /The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:// / * /Another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method./ * /The timeout period, specified by timeout milliseconds plus nanos nanoseconds arguments, has elapsed. / Cheers, Ulf
RE: JEP 132: More-prompt finalization
For what it's worth, I fully agree with David and Kirk around finalization not
necessarily needing this treatment.
However, I was hoping this would have the effect of improving (non-finalizable)
reference handling. We've seen serious issues in WeakReference handling and
have had to write some twisted code to deal with this.
So I guess the question I have to Kirk and David is: do you feel a GC load of
10K WeakReferences per cycle is also doing something else wrong?
Sorry if this is going off-topic.
Thanks
Moh
-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Kirk Pepperdine
Sent: Thursday, May 28, 2015 11:58 PM
To: david.hol...@oracle.com Holmes
Cc: hotspot-gc-...@openjdk.java.net openjdk.java.net; core-libs-
d...@openjdk.java.net
Subject: Re: JEP 132: More-prompt finalization
Hi Peter,
It is a very interesting proposal but to further David's comments, the life-
cycle costs of reference objects is horrendous of which the actual process of
finalizing an object is only a fraction of that total cost. Unfortunately your
micro-benchmark only focuses on one aspect of that cost. In other words, it
isn't very representative of a real concern. In the real world the finalizer
*must compete with mutator threads and since F-J is an all threads on deck
implementation, it doesn't play well with others. It creates a tragedy of the
commons. That is situations where everyone behaves rationally with a common
resource but to the detriment of the whole group. In short, parallelizing (F-
Jing) *everything* in an application is simply not a good idea. We do not live
in an infinite compute environment which means to have to consider the impact
of our actions to the entire group.
This was one of the points of my recent article in Java Magazine which I wrote
to try to counter some of the rhetoric I was hearing in conference about the
universal benefits of being able easily parallelize streams in Java 8. Yes, I
agree it's a great feature but it must be used with discretion. Case in point.
After I finished writing the article, I started running into a couple of early
adopters that had swallowed the parallel message whole indiscriminately
parallelizing all of their streams. As you can imagine, they were quite
surprised by the results and quickly worked to de-parallelize *all* of the
streams in the application.
To add some ability to parallelize the handling of reference objects seems
like a good idea if you are collecting large numbers of reference objects
(10,000 per GC cycle). However if you are collecting large numbers of
reference objects you're most likely doing something else wrong. IME,
finalization is extremely useful but really only for a limited number of use
cases and none of them (to date) have resulted in the app burning through
1000s of final objects / sec.
It would be interesting to know why why you picked on this particular issue.
Kind regards,
Kirk
On May 29, 2015, at 5:18 AM, David Holmes david.hol...@oracle.com wrote:
Hi Peter,
I guess I'm very concerned about the premise that finalization should scale
to millions of objects and be performed highly concurrently. To me that's
sending the wrong message about finalization. It also isn't the most effective
use of cpu resources - most people would want to do useful work on most cpu's
most of the time.
Cheers,
David
On 29/05/2015 3:12 AM, Peter Levart wrote:
Hi,
Did you know that the following simple loop:
public class FinalizableBottleneck {
static boolean no;
@Override
protected void finalize() throws Throwable {
// empty finalize() method does not make the object finalizable
// (it is not even registered on the finalizer's list)
if (no) {
throw new AssertionError();
}
}
public static void main(String[] args) {
while (true) {
new FinalizableBottleneck();
}
}
}
...quickly fills the entire heap with FinalizableBottleneck and internal
Finalizer objects and brings the JVM to a halt? After a few seconds of
running the above program, jmap -histo:live reports:
num #instances #bytes class name
--
1: 50048325 2001933000 java.lang.ref.Finalizer
2: 50048278 800772448 FinalizableBottleneck
There are a couple of bottlenecks that make this happen:
- ReferenceHandler thread synchronizes with VM to unhook Reference(s)
from the pending chain one be one and dispatches them to their respected
ReferenceQueue(s) which also use synchronization for equeueing each
Reference.
- Enqueueing synchronizes with the finalization thread which removes the
Finalizer(s) (FinalReferences) from the finalization queue and executes
them.
- Executing the Finalizer(s) removes them from the doubly-linked list of
all Finalizer(s) which is used to retain them until they are needed and
this synchronizes
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
On 05/29/2015 09:28 AM, Mandy Chung wrote: On 05/29/2015 12:20 AM, Xueming Shen wrote: It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. Perhaps better to merge it now rather than separately? But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ...
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset. -Ulf
Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
On 5/29/15 4:02 PM, Ulf Zibis wrote: Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset. No, it's not a must to have a separate class for each charset, but it's a logical way to organize those charset with their data. Given how most of these charsets are src-generated in current jdk, it's fair easy to actually generate a charset object from a base classes (SingleByte, or DoubleByte) + a set of data ( such as the name, aliases table, mapping data, etc) during runtime, without having a real concrete charset class. But then you need to figure out a better way to organize, store and read/initialize those data in a optimized way to initialize each charset on the fly, which we are now utilizing the jvm's class initialization mechanism to achieve this. Any benefit/advantage of doing this? We might throw in some resource someday to gather some data ... -Sherman
Re: RFR: 8081536 : (process) remove unreliable ScaleTest from process tests
Approved; cheers, -Joe On 5/29/2015 12:13 PM, Roger Riggs wrote: Please review the removal of the java/lang/ProcessHandle/ScaleTest for ProcessHandles. It is not appropriate for regression testing and does not run reliably. It was inadvertently included in the commit. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-scaletest-remove-8081536/ Issue: 8081536 https://bugs.openjdk.java.net/browse/JDK-8081536: (process) remove unreliable ScaleTest from process tests Thanks, Roger
RFR: 8081536 : (process) remove unreliable ScaleTest from process tests
Please review the removal of the java/lang/ProcessHandle/ScaleTest for ProcessHandles. It is not appropriate for regression testing and does not run reliably. It was inadvertently included in the commit. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-scaletest-remove-8081536/ Issue: 8081536 https://bugs.openjdk.java.net/browse/JDK-8081536: (process) remove unreliable ScaleTest from process tests Thanks, Roger
