Re: RFR: jdk9: 8029997: [infra] remove Solaris ISA directories and the links
On 12/21/2013 12:08 AM, Alan Bateman wrote: On 20/12/2013 23:03, Kumar Srinivasan wrote: Hello, Please review the removal of ISA (Instruction Specific Architecture) directories namely sparcv9, amd64 and the symlinks in these directories, this was provided to aid transition to jdk8, where solaris 32-bit was removed, and the 32-bit binaries were replaced with 64-bit versions. http://cr.openjdk.java.net/~ksrini/8029997/webrev.0/ This looks good to me too (I assumed there would be several tests that needed adjustment, it seems not). There were :), I nailed those when I removed 32-bit in jdk8. Thanks Tim and Alan. Kumar -Alan.
Why do we need LinkOption.NOFOLLOW_LINKS on the target file in CopyMoveHelper.copyToForeignTarget?
Hi,
while running the jdk/jtreg tests for our ppc-aix-port I found a
problem for the demo/zipfs/basic.sh test on AIX:
Exception in thread main java.io.IOException: NOFOLLOW_LINKS is not
supported on this platform
at sun.nio.fs.UnixPath.openForAttributeAccess(UnixPath.java:773)
at
sun.nio.fs.UnixFileAttributeViews$Basic.setTimes(UnixFileAttributeViews.java:74)
at java.nio.file.CopyMoveHelper.copyToForeignTarget(CopyMoveHelper.java:135)
at java.nio.file.CopyMoveHelper.moveToForeignTarget(CopyMoveHelper.java:157)
at java.nio.file.Files.move(Files.java:1395)
at ZipFSTester.test1(ZipFSTester.java:141)
at ZipFSTester.main(ZipFSTester.java:50)
The test calls java.nio.file.Files.move() without any CopyOptions.
Files.move() in turn calls
java.nio.file.CopyMoveHelper.moveToForeignTarget() which adds the two
CopyOptions LinkOption.NOFOLLOW_LINKS and
StandardCopyOption.COPY_ATTRIBUTES before calling
CopyMoveHelper.copyToForeignTarget().
CopyMoveHelper.copyToForeignTarget() finally checks that the source
file is no symbolic link and performs the copy operation. In a last
step it also copies the file attributes of the source file to the
target file. For this operation it first calls
Files.getFileAttributeView(target, BasicFileAttributeView.class,
linkOptions) before the new attributes are set with
sun.nio.fs.UnixFileAttributeViews$Basic.setTimes(). But operation will
always fail on system like AIX which do not support NOFOLLOW_LINKS (or
more exactly the O_NOFOLLOW flag to the open system call). See the
stack trace above.
However, I don't think that we need to set the
LinkOption.NOFOLLOW_LINKS option when calling
Files.getFileAttributeView() on the target file, because the target
file can not be a symbolic link anyway for two reasons: first of all,
copyToForeignTarget() already checks that the source file is no
symbolic link and it deletes 'target' it that should exist before.
So from my point of view it would be safe to change
CopyMoveHelper.copyToForeignTarget() as follows to make it work an
systems which don't support NOFOLLOW_LINKS:
--- a/src/share/classes/java/nio/file/CopyMoveHelper.java Fri
Dec 20 17:52:39 2013 +0100
+++ b/src/share/classes/java/nio/file/CopyMoveHelper.java Mon
Dec 23 16:33:43 2013 +0100
@@ -130,7 +130,7 @@
// copy basic attributes to target
if (opts.copyAttributes) {
BasicFileAttributeView view =
-Files.getFileAttributeView(target,
BasicFileAttributeView.class, linkOptions);
+Files.getFileAttributeView(target,
BasicFileAttributeView.class);
try {
view.setTimes(attrs.lastModifiedTime(),
attrs.lastAccessTime(),
What do you think, did I miss something? If nobody objects, I'll put
this small change in the next AIX bug fix collection.
Thank you and best regards,
Volker
RFR: 8029231: Update copyright years for files in corba repository for 2013
Some simple copyright year updates which should have been done during the year when these corba files were touched. I hope to push to JDK 8 and then import the patch into JDK 9. https://bugs.openjdk.java.net/browse/JDK-8029231 http://cr.openjdk.java.net/~coffeys/webrev.8029231/webrev/ regards, Sean.
RFR: 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Update copyright date on JAXP files in jdk8 repository edited in 2013. This patch will be applied to JDK8 and 9 repositories. https://bugs.openjdk.java.net/browse/JDK-8029236 http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/ Thanks, Joe
Re: RFR: 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Looks ok assuming they were all modified Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad On Dec 23, 2013, at 12:56 PM, huizhe wang huizhe.w...@oracle.com wrote: Update copyright date on JAXP files in jdk8 repository edited in 2013. This patch will be applied to JDK8 and 9 repositories. https://bugs.openjdk.java.net/browse/JDK-8029236 http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/ Thanks, Joe
Re: RFR: 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Thanks Lance! The patch were SQE-generated based on files changed in 2013. Joe On 12/23/2013 10:10 AM, Lance @ Oracle wrote: Looks ok assuming they were all modified http://oracle.com/us/design/oracle-email-sig-198324.gifLance Andersen| Principal Member of Technical Staff | +1.781.442.2037 tel:+1.781.442.2037 Oracle Java Engineering 1 Network Drive x-apple-data-detectors://34/0 Burlington, MA 01803 x-apple-data-detectors://34/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPad On Dec 23, 2013, at 12:56 PM, huizhe wang huizhe.w...@oracle.com mailto:huizhe.w...@oracle.com wrote: Update copyright date on JAXP files in jdk8 repository edited in 2013. This patch will be applied to JDK8 and 9 repositories. https://bugs.openjdk.java.net/browse/JDK-8029236 http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/ http://cr.openjdk.java.net/%7Ejoehw/jdk8/8029236/webrev/ Thanks, Joe
Re: RFR: 8029231: Update copyright years for files in corba repository for 2013
The patch looks good. Mandy On 12/23/13 9:04 AM, Seán Coffey wrote: Some simple copyright year updates which should have been done during the year when these corba files were touched. I hope to push to JDK 8 and then import the patch into JDK 9. https://bugs.openjdk.java.net/browse/JDK-8029231 http://cr.openjdk.java.net/~coffeys/webrev.8029231/webrev/ regards, Sean.
Re: RFR: 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
The copyright date update looks fine. Mandy On 12/23/13 9:56 AM, huizhe wang wrote: Update copyright date on JAXP files in jdk8 repository edited in 2013. This patch will be applied to JDK8 and 9 repositories. https://bugs.openjdk.java.net/browse/JDK-8029236 http://cr.openjdk.java.net/~joehw/jdk8/8029236/webrev/ Thanks, Joe
hg: jdk8/tl/corba: 8029231: Update copyright years for files in corba repository for 2013
Changeset: 5ca1b4c282b8 Author:ssides Date: 2013-12-23 18:42 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5ca1b4c282b8 8029231: Update copyright years for files in corba repository for 2013 Reviewed-by: mchung, coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/io/OutputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/StubDelegateImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/InvocationHandlerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/DefaultSocketFactoryImpl.java ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/idl_zh_CN.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_ja.prp ! src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable_zh_CN.prp ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/sun/rmi/rmic/iiop/CompoundType.java
Re: RFR for JDK-6772009 Intermittent test failure: java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java test failed with 'Completed != 2'
Hi David/Martin, could any one of you sponsor this change for me? --- Thanks kalyan On 12/20/2013 10:28 PM, David Holmes wrote: On 21/12/2013 4:19 AM, srikalyan wrote: Hi David, i retained only the changes to ITERS, ProbleMList.txt and upstream changes by Doug Lea(as pointed by Martin), could you please review the new change available here http://cr.openjdk.java.net/~srikchan/Regression/6772009-CancelledLockLoop-webrev/ . Ok. Thanks, David -- Thanks kalyan Ph: (408)-585-8040 On 12/19/13, 8:10 PM, David Holmes wrote: Sorry Kalyan but I don't see the need for all the incidental changes if the primary change is to just increase the iterations. I also don't see why you need to do anything for BrokenBarrierException as it is not expected to happen and the test should just fail if it does. David On 10/12/2013 6:15 AM, srikalyan wrote: Hi David/Martin a gentle reminder for review. -- Thanks kalyan Ph: (408)-585-8040 On 12/2/13, 11:21 AM, srikalyan wrote: Hi David, Thanks for the review, the new webrev is hosted at http://cr.openjdk.java.net/~cl/host_for_kal/6772009-CancelledLockLoop/ . Please see inline text. On 11/20/13, 6:35 PM, David Holmes wrote: On 21/11/2013 10:28 AM, Martin Buchholz wrote: I again tried and failed to reproduce a failure. Even if I go whole hog and multiply TIMEOUT by 100 and divide ITERS by 100, the test continues to PASS. Is it just me?! I think you are going the wrong way Martin - you want the timeout to be smaller than the time it takes to execute ITERS. I don't think there's any reason to make result long. It's not even used except to inhibit hotspot optimizations. +private volatile long result = 17;//Can get int overflow,so using long Further the subsequent use of += is incorrect as it is not an atomic operation. Even if we don't care about the value, it looks bad. Made the necessary changes for atomic update. I'm not sure result must be updated if we get a BrokenBarrierException either. Probably harmless, but necessary? I retained it in the fix for completeness in updating the numbers, please let me know if you still think otherwise. need to fix spelling and spacing below. +barrier.await();//If a BrokeBarrierException happens here(due to There are a number of style issues with spacing around comments. Fixed the spelling error and styling issues. And I don't think this change is sufficient to claim co-author status with Doug either ;-) Removed the claim :) The additional tracing may be useful but seems stylistically different from the rest of the code. Retained the tracking to understand if it is again the timing issue which is the cause in an event of a failure, however i can remove it if you think it is not necessary (OR) include an alternate solution as you may want to suggest. Overall I'm suspicious that the changed timeout actually fixes anything - normally we need to add longer timeouts not shorter ones. Does this fail on a range of machines or only specific ones? Have we verified that the clocks/timers are behaving properly on those systems? Here the time out is not about waiting for threads to complete something but to be interrupted before being considered done, so we decreased the timeout. However we now chose to increase the number of iterations to 500 from 100(thanks to tristan for the suggestion) instead of decreasing the timeout as done earlier because the increasing iterations ensures the threads are busy for long time curtailing the need to touch the timeout. Thanks, David -- Thanks kalyan Ph: (408)-585-8040 On Wed, Nov 20, 2013 at 11:52 AM, srikalyan srikalyan.chandrashe...@oracle.com wrote: Hi Martin , apologies for the delay , was trying to get help for hosting my webrev. . Please see inline text. On 11/19/13, 10:35 PM, Martin Buchholz wrote: Hi Kalyan, None of us can review your changes yet because you haven't given us a URL of your webrev. It is located here http://cr.openjdk.java.net/~cl/host_for_srikalyan_6772009_CancelledLockLoops/ I've tried to make the jsr166 copy of CancelledLockLoops fail by adjusting ITERS and TIMEOUT radically up and down, but the test just keeps on passing for me. Hints appreciated. Bump up the timeout to 500ms and you will see a failure (i can see it consistently on my machine Linux 64bit,8GBRAM,dual cores, with JDK 1.8 latest any promoted build). On Tue, Nov 19, 2013 at 6:39 PM, srikalyan chandrashekar srikalyan.chandrashe...@oracle.com wrote: Suggested Fix: a) Decrease the timeout from 100 to 50ms which will ensure that the test will pass even on faster machines This doesn't look like a permanent fix - it just makes the failing case rarer. Thats true , the other way is to make the main thread wait on TIMEOUT after firing the interrupts instead of other way round, but that would be over-optimization which probably is not desirable as well. The 50 ms was arrived at empirically
hg: jdk8/tl/jaxp: 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013
Changeset: 9a3986b21be4 Author:joehw Date: 2013-12-23 11:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9a3986b21be4 8029236: Update copyright year to match last edit in jdk8 jaxp repository for 2013 Reviewed-by: lancea, mchung ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FeatureManager.java ! src/com/sun/org/apache/xalan/internal/utils/FeaturePropertyBase.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/util/SymbolTable.java ! src/com/sun/xml/internal/stream/Entity.java ! src/com/sun/xml/internal/stream/StaxXMLInputSource.java ! src/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/com/sun/xml/internal/stream/writers/WriterUtility.java ! src/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java ! src/javax/xml/XMLConstants.java ! src/javax/xml/parsers/SAXParser.java ! src/javax/xml/validation/Validator.java ! src/javax/xml/xpath/XPathException.java ! src/javax/xml/xpath/XPathFactory.java ! src/org/xml/sax/helpers/NewInstance.java ! src/org/xml/sax/helpers/ParserAdapter.java ! src/org/xml/sax/helpers/ParserFactory.java ! src/org/xml/sax/helpers/SecuritySupport.java ! src/org/xml/sax/helpers/XMLReaderFactory.java
Update on 8014320
Hello, I've been quiet because real life needed my attention. Obviously, the Schoenhage-Strassen and Barrett algorithms are not going to make it into JDK8. I hope that is not a problem for anyone. We shouldn't use the word problem anyway but rather think of it as an opportunity :-) for more refinement and testing. Improvements I have planned are: * Compact storage of DFT vectors. At the moment, they are stored as numbers modulo 2^2^(n+1) when (2^2^n)+1 would suffice. This will save memory and may speed up the DFT and IDFT steps. * Use Bailey's algorithm recursively if it improves cache locality and doesn't add too much complexity to the code. * Maybe add a multiplyParallel() method, now that dft() and idft() use Bailey's algorithm which should make them easy to parallelize. * See if dft() and idft() can be made faster on 64-bit CPUs by using long[][] arrays instead of int[][]. As always, comments are welcome. Merry Chris... I mean, Holidays and a happy new year to everyone! Tim
hg: jdk8/tl/jdk: 2 new changesets
Changeset: aef6c726810e Author:mullan Date: 2013-12-23 14:03 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aef6c726810e 8030813: Signed applet fails to load when CRLs are stored in an LDAP directory Summary: Skip JNDI application resource lookup to avoid recursive JAR validation Reviewed-by: vinnie, herrick ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java Changeset: f3c714eeef6c Author:mullan Date: 2013-12-23 14:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c714eeef6c Merge - src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties - test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
Hi Mandy, after some trials i could simulate the failure again (now with
UEH in place), however the UEH now cannot print enough details as it
also tries to allocate memory, when it does Thread.getName()(it
internally creates a String object), printStackTrace() also creates new
WrappedPrintStream object. See the following trace
Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread Reference Handler
ERROR: java.lang.Exception: Reference Handler thread died.
at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:744)
Meanwhile i am trying looking around to actually print something useful
without allocating any new memory.
---
Thanks
kalyan
On 12/20/2013 01:00 PM, srikalyan wrote:
Hi Mandy, yes I ran with JTreg to simulate the failure, i will try the
UEH patch to see if it sheds some light and get back to you. Thanks
for the direction :)
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/19/13, 8:33 PM, Mandy Chung wrote:
Hi Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information. I ran it for 1000 times but not able to duplicate
the failure. Did you run it with jtreg (I didn't)?
Below is the patch to install a thread's uncaught handler that
you can take and try.
diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java
b/test/java/lang/ref/OOMEInReferenceHand
ler.java
--- a/test/java/lang/ref/OOMEInReferenceHandler.java
+++ b/test/java/lang/ref/OOMEInReferenceHandler.java
@@ -51,6 +51,14 @@
return first;
}
+ static class UEH implements Thread.UncaughtExceptionHandler {
+ public void uncaughtException(Thread t, Throwable e) {
+ System.err.println(ERROR: + t.getName() +
exception +
+ e.getMessage());
+ e.printStackTrace();
+ }
+ }
+
public static void main(String[] args) throws Exception {
// preinitialize the InterruptedException class so that the
reference handler
// does not die due to OOME when loading the class if it is
the first use
@@ -77,6 +85,8 @@
throw new IllegalStateException(Couldn't find
Reference Handler thread.);
}
+ referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
+
ReferenceQueueObject refQueue = new ReferenceQueue();
Object referent = new Object();
WeakReferenceObject weakRef = new
WeakReference(referent, refQueue);
On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
Hi David Thanks for your comments, the unguarded part(clean and
enqueue) in the Reference Handler thread does not seem to create any
new objects, so it is the application(the test in this case) which
is adding objects to heap and causing the Reference Handler to die
with OOME. I am still unsure about the side effects of the code
change and agree with your thoughts(on memory exhaustion test's
reliability).
PS: hotspot dev alias removed from CC.
--
Thanks
kalyan
On 12/19/13 5:08 PM, David Holmes wrote:
Hi Kalyan,
This is not a hotspot issue so I'm moving this to core-libs, please
drop hotspot from any replies.
On 20/12/2013 6:26 AM, srikalyan wrote:
Hi all, I have been working on the bug JDK-8022321
https://bugs.openjdk.java.net/browse/JDK-8022321 , this is a
sporadic
failure and the webrev is available here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/
I'm really not sure what to make of this. We have a test that
triggers an out-of-memory condition but the OOME can actually turn
up in the ReferenceHandler thread causing it to terminate and the
test to fail. We previously accounted for the non-obvious
occurrences of OOME due to the Object.wait and the possible need to
load the InterruptedException class - but still the OOME can appear
where we don't want it. So finally you have just placed the whole
for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm
certain that makes the test happy, but I'm not sure it is really
what we want for the ReferenceHandler thread. If the OOME occurs
while cleaning, or enqueuing then we will fail to clean and/or
enqueue but there would be no indication that has occurred and I
think that is a bigger problem than this test failing.
There may be no way to make this test 100% reliable. In fact I'd
suggest that no memory exhaustion test can be 100% reliable.
David
*
**Root Cause:Still not known*
2 places where there is a possibility for OOME
1) Cleaner.clean()
2)
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
On 12/23/2013 2:02 PM, srikalyan chandrashekar wrote:
Hi Mandy, after some trials i could simulate the failure again (now
with UEH in place), however the UEH now cannot print enough details as
it also tries to allocate memory, when it does Thread.getName()(it
internally creates a String object), printStackTrace() also creates
new WrappedPrintStream object. See the following trace
That's what I later also thought that may run into after suggesting UEH
and no object can be allocated at this point.
It worths trying Peter's suggestion to override the modified version of
Reference class with instrumentation and see what you will get.
Mandy
Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread Reference Handler
ERROR: java.lang.Exception: Reference Handler thread died.
at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:744)
Meanwhile i am trying looking around to actually print something
useful without allocating any new memory.
---
Thanks
kalyan
On 12/20/2013 01:00 PM, srikalyan wrote:
Hi Mandy, yes I ran with JTreg to simulate the failure, i will try
the UEH patch to see if it sheds some light and get back to you.
Thanks for the direction :)
--
Thanks
kalyan
Ph: (408)-585-8040
On 12/19/13, 8:33 PM, Mandy Chung wrote:
Hi Srikalyan,
Maybe you can get add an uncaught handler to see if you can get
any information. I ran it for 1000 times but not able to duplicate
the failure. Did you run it with jtreg (I didn't)?
Below is the patch to install a thread's uncaught handler that
you can take and try.
diff --git a/test/java/lang/ref/OOMEInReferenceHandler.java
b/test/java/lang/ref/OOMEInReferenceHand
ler.java
--- a/test/java/lang/ref/OOMEInReferenceHandler.java
+++ b/test/java/lang/ref/OOMEInReferenceHandler.java
@@ -51,6 +51,14 @@
return first;
}
+ static class UEH implements Thread.UncaughtExceptionHandler {
+ public void uncaughtException(Thread t, Throwable e) {
+ System.err.println(ERROR: + t.getName() +
exception +
+ e.getMessage());
+ e.printStackTrace();
+ }
+ }
+
public static void main(String[] args) throws Exception {
// preinitialize the InterruptedException class so that
the reference handler
// does not die due to OOME when loading the class if it
is the first use
@@ -77,6 +85,8 @@
throw new IllegalStateException(Couldn't find
Reference Handler thread.);
}
+ referenceHandlerThread.setUncaughtExceptionHandler(new UEH());
+
ReferenceQueueObject refQueue = new ReferenceQueue();
Object referent = new Object();
WeakReferenceObject weakRef = new
WeakReference(referent, refQueue);
On 12/19/2013 6:57 PM, srikalyan chandrashekar wrote:
Hi David Thanks for your comments, the unguarded part(clean and
enqueue) in the Reference Handler thread does not seem to create
any new objects, so it is the application(the test in this case)
which is adding objects to heap and causing the Reference Handler
to die with OOME. I am still unsure about the side effects of the
code change and agree with your thoughts(on memory exhaustion
test's reliability).
PS: hotspot dev alias removed from CC.
--
Thanks
kalyan
On 12/19/13 5:08 PM, David Holmes wrote:
Hi Kalyan,
This is not a hotspot issue so I'm moving this to core-libs,
please drop hotspot from any replies.
On 20/12/2013 6:26 AM, srikalyan wrote:
Hi all, I have been working on the bug JDK-8022321
https://bugs.openjdk.java.net/browse/JDK-8022321 , this is a
sporadic
failure and the webrev is available here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev/
I'm really not sure what to make of this. We have a test that
triggers an out-of-memory condition but the OOME can actually turn
up in the ReferenceHandler thread causing it to terminate and the
test to fail. We previously accounted for the non-obvious
occurrences of OOME due to the Object.wait and the possible need
to load the InterruptedException class - but still the OOME can
appear where we don't want it. So finally you have just placed the
whole for(;;) loop in a try/catch(OOME) that ignores the OOME. I'm
certain that makes the test happy, but I'm not sure it is really
what we want for the ReferenceHandler thread. If the OOME occurs
while cleaning, or enqueuing then we will fail to clean and/or
enqueue but there would be no indication that has
Re: Bug in Long.parseUnsignedLong
It looks like this could be rearranged to
long result = first * radix + second;
int guard = radix * (int) (first 57);
if (guard = 128 || (result = 0 guard = 128 - Character.MAX_RADIX)) {
…
provided reasonable comments were added. I understand the first part of this
conditional, guard = 128, but the second part eludes me. Would you please
explain this part.
BTW this works for the test case in question, of course.
On Dec 21, 2013, at 2:04 AM, Dmitry Nadezhin wrote:
I can weaken the question:
Is there a reason to prefer extra int multiplication to the cache ?
long result = first * radix + second;
final int GUARD_BIT = 7;
int guard = radix * (int) (first (Long.SIZE - GUARD_BIT));
if (guard = (1 GUARD_BIT) - Character.MAX_RADIX
(guard = (1 GUARD_BIT) || result = 0)) {
. . .
Re: Bug in Long.parseUnsignedLong
We have
first/0x1p57 - 1 JAVA{first57} JAVA{first57} = first/0x1p57.
Here JAVA{.} stands for Java expression with all its truncations and
wrappings.
Expressions without JAVA{.}are exact mathematical expressions.
JAVA{first57} = first/0x1p57 1p64/1p57 = 1p7, radix =
Character.MAX_RADIX = 36, hence
JAVA{(int)(first57)} = JAVA{first57}.
guard = JAVA{radix * (int)(first57)} = radix*JAVA{first57}.
radix*(first/0x1p57 - 1) guard guard = radix*first/0x1p57 .
radix*first/0x1p57 - Character.MAX_RADIX guard guard =
radix*first/0x1p57 .
This means
guard*0xp57 = first*radix first*radix (guard +
Character.MAX_RADIX)*0x1p57
guard*0xp57 = first*radix + second first*radix + second (guard +
Character.MAX_RADIX)*0x1p57 + Character.MAX_RADIX .
Now we shall split by guard.
When guard = 128 = 1p7, we have first*first + second = 1p7 * 1p57 = 1p64
hence overflow always occur in this.
When guard 128 - Character,MAX_RADIX, we have
guard + Character.MAX_RADIX = 127
first*radix + second 127*0x1p57 + 36 0x1p64 , hence overflow doesn't
occur in this.
When 128 - Character.MAX_RADIX = guard guard 128 ,
(128 - Character.MAX_RADIX)*0xp57 = first*radix + second first*radix +
second (127 + Character.MAX_RADIX)*0x1p57 + Character.MAX_RADIX.
0x1p63 (128 - 36)*0xp57 = first*radix + second first*radix + second
(128 + 36)*1p57 + 36 0x1p64 + 0x1p63 .
Hence JAVA{first*radix + second} = (first*radix + second - 0x1p64)
JAVA{result = 0} = JAVA{first*radix + second = 0} = (first*radix + second
= 0x1p64).
Hence overflow is detected correctly in this case too.
On Tue, Dec 24, 2013 at 4:58 AM, Brian Burkhalter
brian.burkhal...@oracle.com wrote:
It looks like this could be rearranged to
long result = first * radix + second;
int guard = radix * (int) (first 57);
if (guard = 128 || (result = 0 guard = 128 - Character.MAX_RADIX)) {
…
provided reasonable comments were added. I understand the first part of
this conditional, guard = 128, but the second part eludes me. Would you
please explain this part.
BTW this works for the test case in question, of course.
On Dec 21, 2013, at 2:04 AM, Dmitry Nadezhin wrote:
I can weaken the question:
Is there a reason to prefer extra int multiplication to the cache ?
long result = first * radix + second;
final int GUARD_BIT = 7;
int guard = radix * (int) (first (Long.SIZE - GUARD_BIT));
if (guard = (1 GUARD_BIT) - Character.MAX_RADIX
(guard = (1 GUARD_BIT) || result = 0)) {
. . .
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
On 12/21/2013 8:50 AM, Peter Levart wrote: Is it possible to get the test output when it fails? It can fail in two different ways. I can't look at the bug (not authorized)... You should be able to look at it now. There isn't any other information besides OOME error. Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread Reference Handler java.lang.Exception: Reference Handler thread died. at OOMEInReferenceHandler.main(OOMEInReferenceHandler.java:105) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:724) Mandy
Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names
Thanks Aleksej for addressing the ACT issue. The l10n files look fine to me. I agree that we should work on translation consistency issues separately the next time we have a translation cycle. thanks, -michael On 13?12?22? 10:14 ??, Aleksej Efimov wrote: Hi, The new version of patch for TimeZone display names update is available. Previous webrev contains incorrect naming for Acre timezone generic name (ACT[] array) across all non-root locales. The name was corrected and test TimeZoneNames_*.properties files were modified accordingly. The new webrev: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/ -Aleksej On 12/20/2013 03:39 PM, Aleksej Efimov wrote: Masayoshi, Thank you for the detailed review and your comments. I tried to address all of them. The responses are below. The new webrev can be found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/ Michael, As Masayoshi mentioned, we have a list of inconsistent translations in translation files. I suggest two approaches to resolve it: 1. Log different bug with all problems in translation files. 2. Wait for the next resource file translation update to address these problems. -Aleksej On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote: On 12/18/2013 6:43 PM, Aleksej Efimov wrote: Hi, Please help to review a fix [1] for 8025051 bug [2]. The following fix includes: Common to all modified files: - All year ranges in the copyright header should be modified accordingly. Fixed. - The translation of time zone generic names were added to all locales. I haven't fully reviewed translations, especially all \u strings. But I noticed the following. Common to all TimeZoneNames_*.java: - The same generic abbreviation is used for the long name in MET. I thought this was fixed in the root properties... No, the MET is used in root properties both for generic long and short names. I will update these names when new translation update will be available. - Some generic names don't match the style of their standard and/or daylight time names. The same as previous. This is a first large update for generic names and latest translations. All inconsistency in translations will be fixed during next translation update. src/share/classes/sun/util/resources/de/TimeZoneNames_de.java: - Some generic names use Normalzeit. Is that OK? It's not good. But the resolution is same as previous two. src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java: - Chuuk Time isn't translated. I think it will be translated in next translations update. - Time Zone names were updated according to the latest translations. - Added tz names regression test (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names across all locales. This test compares short/long standard/daylight/generic names with translations stored in .properties files. test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java: - lines 33, 34: unused imports? Removed - line 75: Should it be detected as an error? Agree, now the test will fail if there is some incorrect entries in the test .properties files. - line 108: IOException should be used as a cause. (OK to assume not found?) The IOException cause is added. Currently, the test will stop with RuntimeException, because the test file is not found. - lines 118 -121: Locale.getDefault() has to be replaced with Locale.ROOT. Regression tests are run in different locales. Thank you for catching this one. Fixed. - Tests updates to address current changes ( GenericTimeZoneNamesTest.sh and Bug6317929.java). The TODO comment in GenericTimeZoneNamesTest.sh should fully been removed. Removed The following fix was tested with JPRT build and the 'jdk_util' test set succeeded (new test is included in this test set). Have you executed all date-time related regression tests (including java.time and java.text)? Yes, I have executed the following set of tests via JTREG: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/closed/java/util/TimeZone test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar All tests gave PASS results. Please, let me know if you think that some other tests should be executed. Thanks, Masayoshi [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8025051
Re: RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test
Hi Stuart I did an experiment that set a small thread stack size using the -Xss228k or -Xss512k. The result is surprised that jtreg reports the test passed. Although I can see the StackOverflowError showing in the log even when I set thread stack size as 512k . So the problem is old shell script doesn't report the error even there is a StackOverflowError. Thank you. Tristan On 12/21/2013 08:01 AM, Stuart Marks wrote: On 12/19/13 8:29 PM, David Holmes wrote: If you were always one frame from the end then it is not so surprising that a simple change pushes you past the limit :) Try running the shell test with additional recursive loads and see when it fails. David doesn't seem surprised, but I guess I still am. :-) Tristan, do you think you could do some investigation here, regarding the shell script based test's stack consumption? Run the shell-based test with some different values for -Xss and see how low you have to set it before it generates a stack overflow. It's also kind of strange that in the two stack traces I've seen (I think I managed to capture only one in the bug report though) the StackOverflowError occurs on loading exactly the 50th class. Since we're observing intermittent behavior (happens sometimes but not others) the stack size is apparently variable. Since it's variable I'd expect to see it failing at different times, possibly the 49th or 48th recursive classload, not just the 50th. And in such circumstances, do we know what the default stack size is? Classloading consumes a reasonable chunk of stack so if the variance elsewhere is quite small it is not that surprising that the test always fails on the 50th class. I would not expect run-to-run stack usage variance to be high unless there is some random component to the test. Hm. There should be no variance in stack usage coming from the test itself. I believe the test does the same thing every time. The thing I'm concerned about is whether the Java-based test is doing something different from the shell-based test, because of the execution environment (jtreg or other). We may end up simply raising the stack limit anyway, but I still find it hard to believe that the shell-based test was consistently just a few frames shy of a stack overflow. The failure is intermittent; we've seen it twice in JPRT (our internal buildtest system). Possible sources of the intermittency are from the different machines on which the test executes. So environmental factors could be at play. How does the JVM determine the default stack size? Could different test runs on different machines be running with different stack sizes? Another source of variance is the JIT. I believe JIT-compiled code consumes stack differently from interpreted code. At least, I've seen differences in stack usage between -Xint and -Xcomp runs, and in the absence of these options (which means -Xmixed, I guess) the results sometimes vary unpredictably. I guess this might have to do with when the JIT compiler decides to kick in. This test does perform a bunch of iterations, so JIT compilation could be a factor. I don't know if you were able to reproduce this issue. If you were, it would be good to understand in more detail exactly what's going on. FWIW there was a recent change in 7u to bump up the number of stack shadow pages in hotspot as suddenly StackOverflow tests were crashing instead of triggering StackOverflowError. So something started using more stack in a way the caused there to not be enough space to process a stackoverflow properly. Finding the exact cause can be somewhat tedious. This seems like a different problem. We're seeing actual StackOverflowErrors, not crashes. Good to look out for this, though. s'marks Cheers, David s'marks
Re: i18n dev RFR: 8025051: Update resource files for TimeZone display names
Looks good to me. Masayoshi On 12/23/2013 3:14 AM, Aleksej Efimov wrote: Hi, The new version of patch for TimeZone display names update is available. Previous webrev contains incorrect naming for Acre timezone generic name (ACT[] array) across all non-root locales. The name was corrected and test TimeZoneNames_*.properties files were modified accordingly. The new webrev: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/ -Aleksej On 12/20/2013 03:39 PM, Aleksej Efimov wrote: Masayoshi, Thank you for the detailed review and your comments. I tried to address all of them. The responses are below. The new webrev can be found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/ Michael, As Masayoshi mentioned, we have a list of inconsistent translations in translation files. I suggest two approaches to resolve it: 1. Log different bug with all problems in translation files. 2. Wait for the next resource file translation update to address these problems. -Aleksej On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote: On 12/18/2013 6:43 PM, Aleksej Efimov wrote: Hi, Please help to review a fix [1] for 8025051 bug [2]. The following fix includes: Common to all modified files: - All year ranges in the copyright header should be modified accordingly. Fixed. - The translation of time zone generic names were added to all locales. I haven't fully reviewed translations, especially all \u strings. But I noticed the following. Common to all TimeZoneNames_*.java: - The same generic abbreviation is used for the long name in MET. I thought this was fixed in the root properties... No, the MET is used in root properties both for generic long and short names. I will update these names when new translation update will be available. - Some generic names don't match the style of their standard and/or daylight time names. The same as previous. This is a first large update for generic names and latest translations. All inconsistency in translations will be fixed during next translation update. src/share/classes/sun/util/resources/de/TimeZoneNames_de.java: - Some generic names use Normalzeit. Is that OK? It's not good. But the resolution is same as previous two. src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java: - Chuuk Time isn't translated. I think it will be translated in next translations update. - Time Zone names were updated according to the latest translations. - Added tz names regression test (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names across all locales. This test compares short/long standard/daylight/generic names with translations stored in .properties files. test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java: - lines 33, 34: unused imports? Removed - line 75: Should it be detected as an error? Agree, now the test will fail if there is some incorrect entries in the test .properties files. - line 108: IOException should be used as a cause. (OK to assume not found?) The IOException cause is added. Currently, the test will stop with RuntimeException, because the test file is not found. - lines 118 -121: Locale.getDefault() has to be replaced with Locale.ROOT. Regression tests are run in different locales. Thank you for catching this one. Fixed. - Tests updates to address current changes ( GenericTimeZoneNamesTest.sh and Bug6317929.java). The TODO comment in GenericTimeZoneNamesTest.sh should fully been removed. Removed The following fix was tested with JPRT build and the 'jdk_util' test set succeeded (new test is included in this test set). Have you executed all date-time related regression tests (including java.time and java.text)? Yes, I have executed the following set of tests via JTREG: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/closed/java/util/TimeZone test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar All tests gave PASS results. Please, let me know if you think that some other tests should be executed. Thanks, Masayoshi [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8025051
