From mike.skells at talk21.com Tue Nov 1 00:11:25 2011 From: mike.skells at talk21.com (Mike Skells) Date: Tue, 1 Nov 2011 00:11:25 +0000 (GMT) Subject: performance updates to jar and zip In-Reply-To: <4EAF11E2.7000008@oracle.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> <4EAF11E2.7000008@oracle.com> Message-ID: <1320106285.80954.YahooMailNeo@web86608.mail.ird.yahoo.com> Hi Sherman, (1) ?Are the number here with writing the LOC in the background thread, in not I don't understand the comment The writeLOC in the base code version is very slow. each int written is written as 4 seperate bytes, each of which takes out locks, checks to flush etc In the version that I submitted I rewrote this to write to a temporary buffer Running a profiler on you code to look for the CPU/Elapsed time I see (all figure are for the CPU/Elapsed time as a proportion of the main thread CPU/elapsed time total, and include time in called methods method writeLOC 16.7%/16% of ?which ZipCoder.getBytes 9.9%/8.9% To put this is proportion the BufferedOutputStream.write is 2.5%, 4.8% (2) Iti is true that this is not a performance gain by code improvement, but it is a performnce gain by specification. The same arguement applies to allowing a Zip Compression of 1 rather than the default. As for the spec, all I have seen is that it should provide the date is available. I am not that fussed if we include this in another section and I that all specification changes need to be considered seperately, as long as it is not lost I ran you test and I did not see more than 15% difference in the scanning with jav2DosTime includes/excluded. Minimal time in profiler reported as well Running the same time on the same files via the sample improved app that you supplied I see 16% of the time spent in javaToDosTime Could this be a micro-benchmark issue? (aqnd/or a profiling issue)? In the benchmarks that I have for the full jar app I see usually 5-10% total time reduction in the tests that are CPU bound (3) It will not give much advantage if we have to process the files in a strict order, and really is part of the app structure not the improvements, ie the mechaism of how the pipeline work (4) It is ather hard to quantify the benifit of the approach. Certainly all of the code that I had did not lock the main thread until the IO buffers are full, so generally the thread didnt block until the data was ready to be pushed to the output. I am not sure that there is much extra complexity introduced by using a j.u.c.CompletionQueue, and the main thread polls that? (5) if w want to limit memory use then a Semaphore would better avoid lots of JC cycles, which could adversely affect other part sof the system. I used a memory pool, so that the memory was not cycled and didnt grow, which seems a more efficient solution, but slightly more complex (6) I hd not expected to have a large impact of the u.u.zip package, but I think a Parallel ZipWriter is useful. I included 2 basic implementations, one that wrote bases in the user managing threads, and one that defferred to a Executor. The user APi for that is similar to ZipOutputStream, but has a simper API, in that you write an entry with and InputStream, and the implementation manages the parallelism. I would think that a capability for a parallel ZIP encoding stream would be a benifit to the community in general The majority of the code that I presented ?in the j.u.Zip and j.u.jar packages are for investigation (e.g. nio vs RandomAccessFile), and were only left in because I could not verify that the RandomAccessFile based IO was faster than nio channel based IO, and to verify If there was a better approach (other) one other improvement in Zip is related to the handling of stored mode. In the standard delivery the file is read twice, once to calculate the CRC and again to write the data Regards Mike >________________________________ >From: Xueming Shen >To: Mike Skells >Cc: "core-libs-dev at openjdk.java.net" >Sent: Monday, 31 October 2011, 21:23 >Subject: Re: performance updates to jar and zip > > > >Hi Mike, > >(1) While it's not a "significant benefit" :-)? obviously it helps the through put to move the "loc writing" >to the background work (together with the compression).? I notice 10%+ improvement on one of my >4-core machine (vm OS installation, so the IO is supposed to be slow), when increasing the threads >from 3-4. > >@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cf rt.jar rtjar >Warmup:rtjar...done >Jar TotalTime:7211 > >[@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cfT3 rt.jar rtjar >Warmup:rtjar...done >mtCreate: threadNum=3... >Jar TotalTime:3266 > >[@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cfT4 rt.jar rtjar >Warmup:rtjar...done >mtCreate: threadNum=4... >Jar TotalTime:2754 > >(2) It's definitely fine with me to have a separate discussion regarding whether or not jar should >have a -D like option for those know that they will never need the lastModified info in the jar/zip >file they create. But I don't think we should count/include the time saved from using -D into the >"performance improvement/gain" here,? you trade off the functionality for speed here, especially >this info is something specified by default in loc/cen tables. > >I also tried that javaToDosTime calculation in FIter2.java > >http://cr.openjdk.java.net/~sherman/mtjar2/FIter2.java > >I did not see any significant performance impact by doing? javaToDosTime calculation, if I did not >mis-understand what you meant. > >(3) I actually tried ArrayBlockingQueue, but it does not appear to help the performance in my setup, >actually it slowdown the process a little, so I took it off the table. I might give it a try later. > >(4) Not separating the file loading and compression is by purpose, this way it helps to preserve the >"order" of the files/dir scanned. The cost is as you suggested the main thread might get blocked on >the queue, if the first in line has not finished the load/compression yet. But? I did not see an easy way >to preserve the sequential order by using a separate "completed" queue (doable, but makes thing >complicated). While preserving the "order" is not a hard request,? zip spec never specifies the order >/structure of entries included, I don't any reason to break the existing behavior if the change does >not bring in something significant. > >(5) There is potential memory issue with the current code, in worse case if the writing thread can >not catch up with all compressing threads and you have an "unlimited" files to zip in. It can be >addressed by either monitoring the memory usage or simply wrap the allocation with the try >block, if we exhaust the memory, just pass the file directly without submit it into the job queue. >But this is something we can consider later, the purpose of my code is to have some measure >to see how far we can go, mostly because we don't have your code work on jdk8 yet. > >(6) I would not expect that we are going to add bunch of new public classes/apis just for this >particular performance tuning, if those classes/apis don't bring in too much value for general >jar/zip operation, for example, in my experimental code, I've added ZOS.writeNextEntry >for the convenience of the experimenting/testing, but if we finally go this direction, I would >assume we will end up having a "customized" ZipOutputStream in sun.tool.jar for this purpose >instead of exposing that "writeNextEntry" API, as it probably serves nobody.? Yes, that means >those "public" classes/APIs in your proposal will have to have a very good story to back them >to be "public". > >I'm looking for a workable JDK8 patch to test/work on:-)? we need some data first, and then >decide what will be in and what will be left behind. > >-Sherman >? > >http://cr.openjdk.java.net/~sherman/mtjar2/webrev/ > >On 10/27/2011 4:07 PM, Mike Skells wrote: >Hi Sherman, >>I think that you will get significant benefit from generating the data structures in the background threads. >>I think that is you profile the usageyou will see that the generation of the header information is the dominant feature.? >>That is why I parallelised the writing process.? >> >> >>There are several bottlenecks such as the encoding of the name name and (although you dismiss it) the calculation of the dos time format is a CPU hog (the -D qualifier). I hink that it is about 10% of the overall CPU load >> >> >>This is by the way pretty much in line with the extraction feature below added in java 6, so I cant see that there is a great reason against it,? >>after all why spend time storing information that (in most use cases) is not read (either because the jar utility does not by default maintain it, and most jar files are? >>probably not expanded anyway >>/** >>? ? ?* If true, maintain compatibility with JDK releases prior to 6.0 by >>? ? ?* timestamping extracted files with the time at which they are extracted. >>? ? ?* Default is to use the time given in the archive. >>? ? ?*/ >>? ? private static final boolean useExtractionTime = >>? ? ? ? ? ? Boolean.getBoolean("sun.tools.jar.useExtractionTime");? >> >> >> >> >>Here are the times that I get running the code that you wrote on my setup >> >> >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10279 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT1, cfT1, 9652 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 6139 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5683 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 6102 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 6172 >> >> >>I think that the reason that it tails off in performance is rather that you are overloading the system with the background threads. You have many threads (ie > cores) loading the files, and they are contending for the CPU >>and the writer thread is not getting its share of time, so with 3 threads + the initail file scanning and the writer thread there are more threads that can be services >> >> >>If you introduce an ArrayBlockingQueue for both of the scanning -> compression and the compression->writing? >>and also get run of the cpu bound ( until the scanner gets going) polling like >>?while(true) { >> >>? ? ? Object o = elist.poll(); >>? ? ? if (o == null) >>? ? ? ? ? ? continue; >> >> >>I dont think that you have the seperation of the loading and storing sorted out. The code adds the future to elist, and the worker thread reads it whether or not it has completed,? >>so some times the loading is done on the background thread before the main thread reads it, and sometimes it blocks, even when other jobs have completed, so I think that a completion queue? >>works better for this. It will complicate the END processing though >> >> >>If I am reading the code correctly I think that there are potential memory issues. >>There are an unlimitted number of jobs submitted to an executor, which while it only executes T jobs, the jobs may still queue up in elist, and each job can buffer 50Mb of data. If the writing of the output is too slow you could run out of memory >> >> >>Line 666 and 672 (both return statements ) I think should be continue; >> >> >>With T1 there is no effective pipelining as I see it. The scannign thread has to complete before the loading thread can start (as there is only 1 CPU). So withthe blocking thread model we have to start at 2 threads as otherwise it may deadlock itself >> >> >>with a blocking queue (and minor changes caused or implied by a blocking queue) >> >> >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf, cf, 10274 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT2, cfT2, 7201 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT3, cfT3, 5836 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT4, cfT4, 5884 >>C:\Program Files\Java\jdk1.7.0\bin\java.exe ?-Xbootclasspath/p:, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cfT5, cfT5, 5890 >> >> >>I tried to repoduce the exception that you have, but I cant >>I donw have a java8 install on this machine, or unix. >>It does seem very strange that there is a file being written as "../" in the first place though ( let alone a duplicate) >>I didnt think that any of the API would return ../ >>Is it only on Z3 that this error occurs? >> >> >>I will install a Java8 with the patch, but it will be at the start of next week >> >> >>regards >> >> >>Mike >> >> >> >> >> >>>________________________________ >>>From: Xueming Shen >>>To: core-libs-dev at openjdk.java.net >>>Sent: Thursday, 27 October 2011, 0:19 >>>Subject: Re: performance updates to jar and zip >>> >>>Hi Mark >>> >>>It appears the patch you provided throws unexpected exception (attached at the end of my >>>email)? when I tried it out on the? latest JDK8 repository.? Since I only did a quick scan of your >>>patch, I'm not sure what went wrong here. >>> >>>This patch includes lots of stuff that obviously you are trying/testing on, as you "warned" us in >>>your email, I can see at least it tries to >>> >>>(1) to support different compression level 0-9 >>>(2) parallel Zip file writing >>>(3) with various m-thread strategy -Z >>>(4) Files.walkFileTree instead of File.list >>>(5) the -D :-) which I would really not recommend to do >>>(6) small optimization in various places. >>> >>>which makes the code a little hard to read and the resulting data hard to compare with. >>>I would suggest to divide this proposal to separate pieces and work on them one by one, >>>for example maybe we can try to solve the main puzzle (2) + (3) first, and then the other >>>optimization opportunities. >>> >>>To collect some data, I followed your lead to write a simple MT support implementation >>>in Jar Main class as showed at >>> >>>http://cr.openjdk.java.net/~sherman/mtjar2/webrev2/ >>> >>>which I guess is similar to what your are doing. It uses a "simple" strategy >>> >>>(1) A dedicated thread (from the ExecutorService thread pool) to iterate the file system >>>? ? tree to "collect" the target files,? submit a "compression? job" for? each of these files >>>? ? to the ExecutorService and keep the returned "Future" (from the submission) in a >>>? ? queue "elist". >>>(2) Threads from ExecutorService to use temporary buffer memory to read and compress >>>? ? ? the the file in memory . >>>(3) The main thread is polling the queue "elist", waiting for the "compression job" to >>>? ? cmplete and? write the result into the target ZipOutputStream. >>> >>>The resulting data looks promising, I'm seeing the jar-ing speed doubled when jar-ing >>>the rt.jar and a jdk7 binary tree, on a "slow" but 4-core linux vm machine (I have the >>>similar result on a 2-hcore linux as well) >>> >>>java Jar cf jdk.jar jdk1.7.0? ? ? ? Jar TotalTime:17278 >>>java Jar cfT1 jdk.jar jdk1.7.0? Jar TotalTime:12345 >>>java Jar cfT2 jdk.jar jdk1.7.0? Jar TotalTime:7559 >>>java Jar cfT3 jdk.jar jdk1.7.0? Jar TotalTime:7572 >>>java Jar cfT4 jdk.jar jdk1.7.0? Jar TotalTime:7801 >>>java Jar cfT5 jdk.jar jdk1.7.0? Jar TotalTime:8112 >>> >>>The new "T" option for "n-thread", the digit number followed is to specify the >>>fixed thread number for the executor service's thread pool.? It appears that we can >>>achieve the "best" result with only 3 threads in this configuration. One thread for >>>scanning the file system, one thread for the compression and the main thread for >>>the writing out. My guess is that the fact we have to "write out" to a single file >>>(the resulting jar) limits the potential benefit of having more "compressing" threads. >>> >>>I also tried to measure the "file scanning" speed in my mini-benchmark FIter >>> >>>http://cr.openjdk.java.net/~sherman/mtjar2/FIter.java >>> >>>Here are the "surprising" results. >>> >>>"nio" is the walkFileTree, >>>"io" is the File.list() >>>"io2" is the File.listFiles(). >>> >>>The nio's File.walkFileTree is 15 times faster than the "traditional" recursion+File.list(). >>>wow! >>> >>>Linux-------------------------------------------------------------------------- >>>sherman at sherman-linux:~/Workspace/test$ java FIter ../jdk8_mtJar/src >>>java.io.File iteration >>>------------------ >>>? nio.totalSize:137149279 >>>? ? ? ? fileNum:12222 >>>? ? ? checkSum:16122691809689000 >>>? ? ? ? ? Time:85 >>>------------------ >>>? io.totalSize:137149279 >>>? ? ? ? fileNum:12222 >>>? ? ? checkSum:16122691809689000 >>>? ? ? ? ? Time:269 >>>------------------ >>>io2.totalSize:137149279 >>>? ? ? ? fileNum:12222 >>>? ? ? checkSum:16122691809689000 >>>? ? ? ? ? Time:450 >>> >>>Windows7--------------------------------------------------------------------------------- >>> >>>$ /cygdrive/c/Program\ Files\ \(x86\)/Java/jdk1.7.0/bin/java FIter ../sqa/jdk8/src >>>java.io.File iteration >>>------------------ >>>? nio.totalSize:136695871 >>>? ? ? ? fileNum:12199 >>>? ? ? checkSum:15997350823839479 >>>? ? ? ? ? Time:323 >>>------------------ >>>? io.totalSize:136695871 >>>? ? ? ? fileNum:12199 >>>? ? ? checkSum:15997350823839479 >>>? ? ? ? ? Time:2633 >>>------------------ >>>io2.totalSize:136695871 >>>? ? ? ? fileNum:12199 >>>? ? ? checkSum:15997350823839479 >>>? ? ? ? ? Time:4592 >>> >>> >>>---------------------------------------------------------------------- >>> >>>sherman at sherman-linux:~/Workspace/test$ ../jdk8_mtJar/build/linux-i586/bin/jar cf6DZ3 rt0.jar rtjar >>>duplicate path >>>java.util.zip.ZipException: duplicate entry: ../ >>>? ? at java.util.zip.AbstractZipWriter.writeHeader(AbstractZipWriter.java:647) >>>? ? at java.util.zip.AbstractZipWriter.startWritingStored(AbstractZipWriter.java:384) >>>? ? at java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:350) >>>? ? at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) >>>? ? at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) >>>? ? at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) >>>? ? at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>>? ? at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>? ? at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>>? ? at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) >>>? ? at java.util.concurrent.FutureTask.run(FutureTask.java:166) >>>? ? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>>? ? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>>? ? at java.lang.Thread.run(Thread.java:722) >>>java.util.concurrent.ExecutionException: java.util.zip.ZipException: duplicate entry: ../ >>>? ? at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) >>>? ? at java.util.concurrent.FutureTask.get(FutureTask.java:111) >>>? ? at sun.tools.jar.Main.waitFor(Main.java:810) >>>? ? at sun.tools.jar.Main.run(Main.java:679) >>>? ? at sun.tools.jar.Main.main(Main.java:1842) >>>Caused by: java.util.zip.ZipException: duplicate entry: ../ >>> >>>-Sherman >>> >>>On 10/20/2011 3:55 PM, Mike Skells wrote: >>>> Hi All, >>>> I have some performance updates for the jar tool and for the Zip/Jar writing components, including some code to allow parallel writing of Jar and ZIP files (in java.util) >>>> This work is not finished as yet but I am looking to see if anyone has any views as to the shape this should move in >>>> Currently it is a testbed for comparing different techniques, but largely based on the Jar utility >>>> >>>> The changes allow the work to be spread across multiple CPUs and optimise the some of the code and I/O paths >>>> >>>> This comparative figures do not include the effect of the nio changes that I proposed in earlier emails >>>> >>>> Command line changes >>>> 0--9 - I have added support for specifying different compression levels (the existing jar command just allows default compression or '0' for no compression >>>> D This allows the files to all be written with the date of now, lather than the file date? (the conversion of the date to zip format is a CPU hog, and not needed in some use-cases) >>>> Z0-5 - these are the different mechanisms to allow different parallel execution models - I would not expect this to be a production qualifier >>>> >>>> The test environment is a 4 core Intel core2 pc running windows? vista 64, the test case is jaring up the content of rt.jar to a jar file. Each test is repeated 6 times and the last 5 are averaged to produce the answers. Each test is run in a fresh VM >>>> >>>> The performance figures are below as a CSV. The last column is the duration of the task in ms. >>>> >>>> In summary the existing jar utility takes (for uncompressed, compressed) 8.4 , 9.4 seconds to complete and this can be reduced to 1.6, 2.3 seconds? >>>> The different parallel algorithms are 0 - none all in one thread as before >>>> 1 - file scanning in one core, 10 threads loading and buffering files, zip writing in a single thread using the existing ZipOuputStream >>>> 2. - file scanning in one core, 10 threads loading and buffering files, zip writing mostly mutithreaded (e.g. parallel compression, single write to the output stream) >>>> 3 - as 2 but writes to a file rather than a stream >>>> 4. as 2 but uses channels to be to write with direct buffers >>>> 5 as 4 but using heap buffers >>>> >>>> 3-5 have the zip capability in the code to seek and update headers that are incomplete, but this is not much tested >>>>? >>>> >>>> >>>> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf0, java 1.6 rt -cf0, 8482 >>>> C:\Program Files\Java\jdk1.6.0_24\bin\java.exe, C:\Program Files\Java\jdk1.6.0_24\lib\tools.jar, -cf, java 1.6 rt -cf, 9318 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf0, java 1.7 rt -cf0, 8497 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Program Files\Java\jdk1.7.0\lib\tools.jar, -cf, java 1.7 rt -cf, 9518 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf0, orig 1.7 rt -cf0, 8448 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\Test\Archive\baseline.jar, -cf, orig 1.7 rt -cf, 9484 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0, project 1.7 rt -cf0, 3133 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0D, project 1.7 rt -cf0D, 2824 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0Z0, project 1.7 rt -cf0 parallel 0, 3026 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ0, project 1.7 rt -cf0D parallel 0, 2961 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ1, project 1.7 rt -cf0D parallel 1, 2022 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ2, project 1.7 rt -cf0D parallel 2, 1757 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ3, project 1.7 rt -cf0D parallel 3, 1632 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ4, project 1.7 rt -cf0D parallel 4, 1994 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf0DZ5, project 1.7 rt -cf0D parallel 5, 1978 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1, project 1.7 rt -cf1, 5237 >>>> >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1D, project 1.7 rt -cf1D, 5073 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1Z0, project 1.7 rt -cf1 parallel 0, 5367 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ0, project 1.7 rt -cf1D parallel 0, 5002 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ1, project 1.7 rt -cf1D parallel 1, 5125 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ2, project 1.7 rt -cf1D parallel 2, 2257 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ3, project 1.7 rt -cf1D parallel 3, 2145 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ4, project 1.7 rt -cf1D parallel 4, 2505 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf1DZ5, project 1.7 rt -cf1D parallel 5, 2549 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf2, project 1.7 rt -cf2, 5371 >>>> >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf3, project 1.7 rt -cf3, 5409 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf4, project 1.7 rt -cf4, 5778 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf5, project 1.7 rt -cf5, 5906 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6, project 1.7 rt -cf6, 6082 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf7, project 1.7 rt -cf7, 6070 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf8, project 1.7 rt -cf8, 6251 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9, project 1.7 rt -cf9, 6191 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6D, project 1.7 rt -cf6D, 5843 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6Z0, project 1.7 rt -cf6 parallel 0, 6095 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ0, project 1.7 rt -cf6D parallel 0, 5907 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ1, project 1.7 rt -cf6D parallel 1, 5957 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ2, project 1.7 rt -cf6D parallel 2, 2388 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ3, project 1.7 rt -cf6D parallel 3, 2351 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ4, project 1.7 rt -cf6D parallel 4, 2694 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf6DZ5, project 1.7 rt -cf6D parallel 5, 2830 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9D, project 1.7 rt -cf9D, 6134 >>>> >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9Z0, project 1.7 rt -cf9 parallel 0, 6258 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ0, project 1.7 rt -cf9D parallel 0, 6066 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ1, project 1.7 rt -cf9D parallel 1, 6203 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ2, project 1.7 rt -cf9D parallel 2, 2490 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ3, project 1.7 rt -cf9D parallel 3, 2361 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ4, project 1.7 rt -cf9D parallel 4, 2788 >>>> C:\Program Files\Java\jdk1.7.0\bin\java.exe, C:\NetBeansProjects\JavaProject1\dist\javaproject1.jar, -cf9DZ5, project 1.7 rt -cf9D parallel 5, 2847 >>>> >>>> regards >>>> Mike >>> >>> >>> > > From xueming.shen at oracle.com Tue Nov 1 00:30:33 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 31 Oct 2011 17:30:33 -0700 Subject: performance updates to jar and zip In-Reply-To: <1320106285.80954.YahooMailNeo@web86608.mail.ird.yahoo.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> <4EAF11E2.7000008@oracle.com> <1320106285.80954.YahooMailNeo@web86608.mail.ird.yahoo.com> Message-ID: <4EAF3DA9.90405@oracle.com> On 10/31/2011 5:11 PM, Mike Skells wrote: > Hi Sherman, > (1) Are the number here with writing the LOC in the background > thread, in not I don't understand the comment > The writeLOC in the base code version is very slow. each int written > is written as 4 seperate bytes, each of which takes out locks, checks > to flush etc > > The number below has the loc written in pooled thread. YES It is faster than writing the loc in main thread. [@flicker-vm2:/tmp/sherman/test]../mtjar-linux/bin/java Jar cfT4 rt.jar rtjar Warmup:rtjar...done mtCreate: threadNum=4... Jar TotalTime:2754 From y.s.ramakrishna at oracle.com Tue Nov 1 00:40:01 2011 From: y.s.ramakrishna at oracle.com (y.s.ramakrishna at oracle.com) Date: Tue, 01 Nov 2011 00:40:01 +0000 Subject: hg: jdk8/tl/jdk: 4243978: (ref) Race condition in Reference.enqueue(); ... Message-ID: <20111101004012.908EC471E8@hg.openjdk.java.net> Changeset: 5f2838744544 Author: ysr Date: 2011-10-31 17:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f2838744544 4243978: (ref) Race condition in Reference.enqueue() 4268317: (ref) Reference.isEnqueued() can return true when instance not enqueued Summary: The reference handler now declares, and assumes, that the discovered field, rather than the next field, is (to be) used to link the entries in the pending list, thus allowing a reference object to be safely enqueued even while it is in the pending state. Also added slightly modified regression tests from the two bug reports. Reviewed-by: mchung, alanb, jcoomes ! src/share/classes/java/lang/ref/Reference.java ! src/share/javavm/export/jvm.h ! src/share/native/common/jdk_util.c + test/java/lang/ref/ReferenceEnqueue.java + test/java/lang/ref/ReferenceEnqueuePending.java From sean.coffey at oracle.com Tue Nov 1 09:47:46 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Nov 2011 09:47:46 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EAD7C42.1000103@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> Message-ID: <4EAFC042.5080907@oracle.com> On 30/10/2011 16:33, Alan Bateman wrote: > On 28/10/2011 19:13, Se?n Coffey wrote: >> This is a second stab at cleaning up the close() and finalize() >> methods for FileInputStream / FileOutputStream / RandomAccessFile >> classes so that all parents/referents sharing the same native >> FileDescriptor are closed out correctly. >> >> With Alan's assistance, we have a better implementation in place >> where we avoid the use of counters and instead cycle through a list >> of shared closeables when a FileDescriptor is being shared. >> >> Bug report (not visible yet) >> http://bugs.sun.com/view_bug.do?bug_id=7105952 >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ >> >> regards, >> Sean. > Thanks for persevering with this somewhat hairy issue. I think the > proposed solution is probably the best approach and it's also very > simple/easy to understand. Folks may ask why FileDescriptor isn't > keeping weak references to the enclosing streams and that's to keep it > simple and avoid the complications that FileInputStream and > FileOutputStream finalizers bring (they are specified to close the > stream which is what lead to the previously messy solution). For the > probably <1% of usages where applications create a stream and then > construct a new stream with its FileDescriptor then it just means that > the otherwise unreferenced stream will remain reachable while the > other stream is reachable. > > One thing that I think would be good is to clarify the javadoc on > exactly how "sharing" of file descriptors is intended to work. I'm not > suggesting you do this as part of this change, but just a reminder > that the javadoc needs improvement. Another point is that I think this > fix should bake for while before thinking about 7u (I realize your > primary interest is 7u but this one clearly needs bake time). I'll add a comment explaining how the sharing should work. Yes - best to have this in jdk8 for a few weeks first before backporting. > > On the changes then it's a pity that the additions to FileDescriptor > have to be duplicated to both implementations. I think we need to look > at going back to one implementation, possibly injecting the field for > the handle at build time. > > Is closeAll missing other.close? I'm also not sure that the suppressed > exception handle is completely right - consider the case that > releaser.close fails after the close of at least two other streams > fails. In that case I think we want the IOException from > releaser.close to be thrown with the IOExcepton from the two streams > to be the suppressed exceptions. If I read the code correctly then one > of them will be the suppressed exception and in turn this will have > the other exceptions as suppressed exceptions. In practical terms I > don't think this is a big deal as the stack trace will have everything. > Are you referring to the parent.close() call ? If otherParents is null, then we only have one reference to this FileDesriptor - i.e the Stream that has called close(). Any exception from releaser.close() becomes the main exception if one is seen there. Any exceptions from the earlier closes are then added as suppressed. I've run some tests on this and it looked to work as expected. (stack trace below) > Minor nit but shouldn't "closed" be private. Also probably should put > the standard comments on attach and closeaAll yes - I'll make that private and clean up the comments. > > The webrev makes it hard to read the changes to the test (did you hg > mv or hg rm/add?). I think moving it from etc to FileDescriptor is a > good idea and you can probably rename it simply to Sharing.java. I used hg rm/add. I guess hg mv would have worked too. The testcase has been modified to test the new closeAll functionality (TestCloseReferentHandling()) - I'll rename as suggested. Might be a day or two before I get to cleaning this up. A few other issues on my work list. regards, Sean. > > -Alan. > v245-sus $/suspool/home/sean/jdk8-tl/jdk/build/solaris-sparc/bin/java SC java.io.IOException: close0 exception!! at java.lang.Throwable.fillInStackTrace(Throwable.java:782) at java.lang.Throwable.(Throwable.java:265) at java.lang.Exception.(Exception.java:66) at java.io.IOException.(IOException.java:58) at java.io.FileInputStream$1.close(FileInputStream.java:302) at java.io.FileDescriptor.closeAll(FileDescriptor.java:208) at java.io.FileInputStream.close(FileInputStream.java:299) at SC.TestCloseReferentHandling(SC.java:295) at SC.main(SC.java:43) Suppressed: java.io.IOException: Bad close operation at java.lang.Throwable.fillInStackTrace(Throwable.java:782) at java.lang.Throwable.(Throwable.java:265) at java.lang.Exception.(Exception.java:66) at java.io.IOException.(IOException.java:58) at SC$BadFileInputStream.close(SC.java:358) at java.io.FileDescriptor.closeAll(FileDescriptor.java:198) ... 3 more Suppressed: java.io.IOException: Bad close operation ... 9 more Suppressed: java.io.IOException: Bad close operation ... 9 more From littlee at linux.vnet.ibm.com Tue Nov 1 13:54:40 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Tue, 01 Nov 2011 21:54:40 +0800 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EAAF0C4.5070806@oracle.com> References: <4EAAF0C4.5070806@oracle.com> Message-ID: <4EAFFA20.1060708@linux.vnet.ibm.com> On 10/29/2011 02:13 AM, Se?n Coffey wrote: > This is a second stab at cleaning up the close() and finalize() > methods for FileInputStream / FileOutputStream / RandomAccessFile > classes so that all parents/referents sharing the same native > FileDescriptor are closed out correctly. > > With Alan's assistance, we have a better implementation in place where > we avoid the use of counters and instead cycle through a list of > shared closeables when a FileDescriptor is being shared. > > Bug report (not visible yet) > http://bugs.sun.com/view_bug.do?bug_id=7105952 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ > > regards, > Sean. > > Hi Sean, If we have 3 FileInputStream which share the same FileDescriptor, and one of the FileInputStream calls its own close. Will other 2 FileInputStream close? I see fd.closeAll is called in the close of FileInputStream, I guess it will close all the things which shared the same fd. -- Yours Charles From sean.coffey at oracle.com Tue Nov 1 14:46:17 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Nov 2011 14:46:17 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EAFFA20.1060708@linux.vnet.ibm.com> References: <4EAAF0C4.5070806@oracle.com> <4EAFFA20.1060708@linux.vnet.ibm.com> Message-ID: <4EB00639.90309@oracle.com> Charles, Yes - all three streams will now be closed. Previous to 7082769, when any of the streams calls close(), the underlying filedescriptor used get closed out via the native close0() call. A list of Closeables is maintained by FileDescriptor. regards, Sean. On 01/11/2011 13:54, Charles Lee wrote: > On 10/29/2011 02:13 AM, Se?n Coffey wrote: >> This is a second stab at cleaning up the close() and finalize() >> methods for FileInputStream / FileOutputStream / RandomAccessFile >> classes so that all parents/referents sharing the same native >> FileDescriptor are closed out correctly. >> >> With Alan's assistance, we have a better implementation in place >> where we avoid the use of counters and instead cycle through a list >> of shared closeables when a FileDescriptor is being shared. >> >> Bug report (not visible yet) >> http://bugs.sun.com/view_bug.do?bug_id=7105952 >> >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ >> >> regards, >> Sean. >> >> > Hi Sean, > > If we have 3 FileInputStream which share the same FileDescriptor, and > one of the FileInputStream calls its own close. Will other 2 > FileInputStream close? > > I see fd.closeAll is called in the close of FileInputStream, I guess > it will close all the things which shared the same fd. > From littlee at linux.vnet.ibm.com Tue Nov 1 14:57:35 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Tue, 01 Nov 2011 22:57:35 +0800 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB00639.90309@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAFFA20.1060708@linux.vnet.ibm.com> <4EB00639.90309@oracle.com> Message-ID: <4EB008DF.5080503@linux.vnet.ibm.com> On 11/01/2011 10:46 PM, Se?n Coffey wrote: > Charles, > > Yes - all three streams will now be closed. Previous to 7082769, when > any of the streams calls close(), the underlying filedescriptor used > get closed out via the native close0() call. > > A list of Closeables is maintained by FileDescriptor. > > regards, > Sean. > > On 01/11/2011 13:54, Charles Lee wrote: >> On 10/29/2011 02:13 AM, Se?n Coffey wrote: >>> This is a second stab at cleaning up the close() and finalize() >>> methods for FileInputStream / FileOutputStream / RandomAccessFile >>> classes so that all parents/referents sharing the same native >>> FileDescriptor are closed out correctly. >>> >>> With Alan's assistance, we have a better implementation in place >>> where we avoid the use of counters and instead cycle through a list >>> of shared closeables when a FileDescriptor is being shared. >>> >>> Bug report (not visible yet) >>> http://bugs.sun.com/view_bug.do?bug_id=7105952 >>> >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7105952/ >>> >>> regards, >>> Sean. >>> >>> >> Hi Sean, >> >> If we have 3 FileInputStream which share the same FileDescriptor, and >> one of the FileInputStream calls its own close. Will other 2 >> FileInputStream close? >> >> I see fd.closeAll is called in the close of FileInputStream, I guess >> it will close all the things which shared the same fd. >> > Does it change the original mechanism? IIRC, the original will remain the other FileInputStream function well (can read from the under stream), until the fd count become 0. -- Yours Charles From sean.coffey at oracle.com Tue Nov 1 15:09:56 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 01 Nov 2011 15:09:56 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB008DF.5080503@linux.vnet.ibm.com> References: <4EAAF0C4.5070806@oracle.com> <4EAFFA20.1060708@linux.vnet.ibm.com> <4EB00639.90309@oracle.com> <4EB008DF.5080503@linux.vnet.ibm.com> Message-ID: <4EB00BC4.3000401@oracle.com> The fd count was only used if it was the finalizer thread. Any explicit close() call not from finalizer meant that the FD got closed. /* * If FileDescriptor is still in use by another stream, the finalizer * will not close it. */ if ((useCount <= 0) || !isRunningFinalize()) { close0(); } regards, Sean. On 01/11/2011 14:57, Charles Lee wrote: >> > Does it change the original mechanism? IIRC, the original will remain > the other FileInputStream function well (can read from the under > stream), until the fd count become 0. From littlee at linux.vnet.ibm.com Tue Nov 1 15:29:05 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Tue, 01 Nov 2011 23:29:05 +0800 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB00BC4.3000401@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAFFA20.1060708@linux.vnet.ibm.com> <4EB00639.90309@oracle.com> <4EB008DF.5080503@linux.vnet.ibm.com> <4EB00BC4.3000401@oracle.com> Message-ID: <4EB01041.3030401@linux.vnet.ibm.com> On 11/01/2011 11:09 PM, Se?n Coffey wrote: > If FileDescriptor is still /* * If FileDescriptor is still in use by another stream, the finalizer * will not close it. */ if ((useCount <= 0) || !isRunningFinalize()) { close0(); } Hi Sean, Would you please lead me to the file which contains the above code? Is it already in the openjdk8 repos? or is it in your patch? I kind of miss those code.... -- Yours Charles From darryl.mocek at oracle.com Tue Nov 1 17:51:55 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Tue, 01 Nov 2011 10:51:55 -0700 Subject: Code Review Request for 6578042 Message-ID: <4EB031BB.8020608@oracle.com> Hello. Please review this patch to fix Bug #6578042 (System.clearProperty() throws ClassCastException if property value isn't a String). The issue is that through the Hashtable methods, it's possible to add a Property which isn't a String and set it through System.setProperties. clearProperty cast the returned removed object as a String, even if it wasn't a String. Test case provided. Webrev: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Thanks, Darryl From jim.holmlund at sun.com Tue Nov 1 22:50:55 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Tue, 01 Nov 2011 22:50:55 +0000 Subject: hg: jdk8/tl/langtools: 7101933: langtools jtreg tests do not work with jprt on windows Message-ID: <20111101225059.479F9471F7@hg.openjdk.java.net> Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile From david.holmes at oracle.com Tue Nov 1 23:54:35 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Nov 2011 09:54:35 +1000 Subject: Code Review Request for 6578042 In-Reply-To: <4EB031BB.8020608@oracle.com> References: <4EB031BB.8020608@oracle.com> Message-ID: <4EB086BB.3050608@oracle.com> Hi Darryl, On 2/11/2011 3:51 AM, Darryl Mocek wrote: > Hello. Please review this patch to fix Bug #6578042 > (System.clearProperty() throws ClassCastException if property value > isn't a String). The issue is that through the Hashtable methods, it's > possible to add a Property which isn't a String and set it through > System.setProperties. clearProperty cast the returned removed object as > a String, even if it wasn't a String. Test case provided. > > Webrev: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev This fix seems inconsistent with how this non-String problem is handled elsewhere. Eg Properties itself does: public String getProperty(String key) { Object oval = super.get(key); String sval = (oval instanceof String) ? (String)oval : null; return ((sval == null) && (defaults != null)) ? defaults.getProperty(key) : sval; } This will only return actual String values or else null - it won't convert non-String values to Strings. Seems to me that Properties should override remove(Object key) to perform similar logic as getProperty(String key). That would fix the System.clearProperty issue. Or, if you want to confine the change to System do: synchronized(props) { String ret = props.getProperty(key); props.remove(key); return ret; } Not quite as efficient of course. That said, I'd also support a spec change for clearProperty that states that if the property has been set to a non-String value then ClassCastException is thrown. I'm somewhat bemused that Properties didn't override the necessary Hashtable methods to enforce Strings-only in the first place. Cheers, David Holmes From david.holmes at oracle.com Wed Nov 2 00:07:55 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Nov 2011 10:07:55 +1000 Subject: Benchmarks for NIO buffer performance Message-ID: <4EB089DB.5060504@oracle.com> Need to cast a wide net here to try and catch past and present NIO developers/users. I'm looking into refactoring all the generated buffer classes to reduce the number of classes created. Part of that requires a performance comparison between the old and new classes. So I'm looking for any benchmarks that may exist to measure NIO buffer performance. There would have undoubtedly been such benchmarks back when NIO was first developed, but they seem to have been lost - unless someone on these lists know of them. ;-) Please reply to me direct, as well as the lists as I'm not subscribed to nio-discuss. Thanks, David Holmes From littlee at linux.vnet.ibm.com Wed Nov 2 01:13:55 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Wed, 02 Nov 2011 09:13:55 +0800 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB00BC4.3000401@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAFFA20.1060708@linux.vnet.ibm.com> <4EB00639.90309@oracle.com> <4EB008DF.5080503@linux.vnet.ibm.com> <4EB00BC4.3000401@oracle.com> Message-ID: <4EB09953.7060307@linux.vnet.ibm.com> On 11/01/2011 11:09 PM, Se?n Coffey wrote: > The fd count was only used if it was the finalizer thread. Any > explicit close() call not from finalizer meant that the FD got closed. > > /* > * If FileDescriptor is still in use by another stream, the > finalizer > * will not close it. > */ > if ((useCount <= 0) || !isRunningFinalize()) { > close0(); > } > > regards, > Sean. > > On 01/11/2011 14:57, Charles Lee wrote: >>> >> Does it change the original mechanism? IIRC, the original will remain >> the other FileInputStream function well (can read from the under >> stream), until the fd count become 0. > Hi Sean, I finally got the background mail from Alan. No questions from me now. -- Yours Charles From mark.reinhold at oracle.com Wed Nov 2 03:48:01 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 01 Nov 2011 20:48:01 -0700 Subject: Benchmarks for NIO buffer performance In-Reply-To: david.holmes@oracle.com; Wed, 02 Nov 2011 10:07:55 +1000; <4EB089DB.5060504@oracle.com> Message-ID: <20111102034801.46D082E97@eggemoggin.niobe.net> 2011/11/1 17:07 -0700, david.holmes at oracle.com: > I'm looking into refactoring all the generated buffer classes to reduce the > number of classes created. Part of that requires a performance comparison > between the old and new classes. So I'm looking for any benchmarks that may > exist to measure NIO buffer performance. There would have undoubtedly been such > benchmarks back when NIO was first developed, but they seem to have been lost - > unless someone on these lists know of them. ;-) You're correct -- we did write buffer benchmarks at the time, way back in 2000/2001. I'm sure I have them somewhere in my archive; I'll try to dig them out for you soon. - Mark From iris.clark at oracle.com Wed Nov 2 05:27:31 2011 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 1 Nov 2011 22:27:31 -0700 (PDT) Subject: Benchmarks for NIO buffer performance In-Reply-To: <20111102034801.46D082E97@eggemoggin.niobe.net> References: <02> <2011> <10:07:55> <+1000> <4EB089DB.5060504@oracle.com 20111102034801.46D082E97@eggemoggin.niobe.net> Message-ID: Hi, Mark. You gave me a copy of those test when I was working on this bug: 4463011: (bf) View-buffer bulk get/put operations are slow If I recall correctly, I modified the tests for my particular problem and added them to that bug as attachments. iris -----Original Message----- From: Mark Reinhold Sent: Tuesday, November 01, 2011 8:48 PM To: David Holmes Cc: nio-discuss at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: Benchmarks for NIO buffer performance 2011/11/1 17:07 -0700, david.holmes at oracle.com: > I'm looking into refactoring all the generated buffer classes to reduce the > number of classes created. Part of that requires a performance comparison > between the old and new classes. So I'm looking for any benchmarks that may > exist to measure NIO buffer performance. There would have undoubtedly been such > benchmarks back when NIO was first developed, but they seem to have been lost - > unless someone on these lists know of them. ;-) You're correct -- we did write buffer benchmarks at the time, way back in 2000/2001. I'm sure I have them somewhere in my archive; I'll try to dig them out for you soon. - Mark From Alan.Bateman at oracle.com Wed Nov 2 06:35:44 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Nov 2011 06:35:44 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EAFC042.5080907@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> <4EAFC042.5080907@oracle.com> Message-ID: <4EB0E4C0.1040804@oracle.com> On 01/11/2011 09:47, Se?n Coffey wrote: > : > > Are you referring to the parent.close() call ? If otherParents is > null, then we only have one reference to this FileDesriptor - i.e the > Stream that has called close(). It's parent.close() that I'm wondering about. Suppose p1 is the parent, p2 is in otherParents. If p2.close is invoked then it looks like p1's close method will not be invoked, leaving p1 open and the underlying file descriptor closed. > > Any exception from releaser.close() becomes the main exception if one > is seen there. Any exceptions from the earlier closes are then added > as suppressed. I've run some tests on this and it looked to work as > expected. (stack trace below) In this example then the IOException appears to be thrown suppressing one exception. That suppression exception in turn suppresses two others. I had expected that the primary IOException would have suppressed three exceptions. As I said, in practical terms this is much of a concern, just pointing out that it's not exactly as expected. > I used hg rm/add. I guess hg mv would have worked too. You need to use hg mv so that the history can be followed. Also webrev handles it, at least before you create the changeset, so that you can easily see the changes. -Alan. From david.holmes at oracle.com Wed Nov 2 07:22:20 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Nov 2011 17:22:20 +1000 Subject: Benchmarks for NIO buffer performance In-Reply-To: References: <02> <2011> <10:07:55> <+1000> <4EB089DB.5060504@oracle.com 20111102034801.46D082E97@eggemoggin.niobe.net> Message-ID: <4EB0EFAC.7000702@oracle.com> On 2/11/2011 3:27 PM, Iris Clark wrote: > Hi, Mark. > > You gave me a copy of those test when I was working on this bug: > > 4463011: (bf) View-buffer bulk get/put operations are slow > > If I recall correctly, I modified the tests for my particular problem > and added them to that bug as attachments. Thanks Iris. The four tests you refer to exercise a number of the Direct*Buffer* classes. Is there anything similar for the Heap*Buffer* and ByteBufferAs*Buffer classes? :) David > iris > > -----Original Message----- > From: Mark Reinhold > Sent: Tuesday, November 01, 2011 8:48 PM > To: David Holmes > Cc: nio-discuss at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: Benchmarks for NIO buffer performance > > 2011/11/1 17:07 -0700, david.holmes at oracle.com: >> I'm looking into refactoring all the generated buffer classes to reduce the >> number of classes created. Part of that requires a performance comparison >> between the old and new classes. So I'm looking for any benchmarks that may >> exist to measure NIO buffer performance. There would have undoubtedly been such >> benchmarks back when NIO was first developed, but they seem to have been lost - >> unless someone on these lists know of them. ;-) > > You're correct -- we did write buffer benchmarks at the time, way back in > 2000/2001. I'm sure I have them somewhere in my archive; I'll try to dig > them out for you soon. > > - Mark From luchsh at linux.vnet.ibm.com Wed Nov 2 08:56:49 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 02 Nov 2011 16:56:49 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c Message-ID: <4EB105D1.9020401@linux.vnet.ibm.com> Hi core-libs-dev, In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line 626, I found that the scope of "#ifdef __solaris__" might be too narrow, since it also works for some kind of OS which I'm currently working on, such as AIX. So I suggest to just remove the '#ifdef __solaris__' and leave the "#else" to accommodate more conditions, see attachment 'patch.diff'. I think this may enhance the cross-platform ability, any ideas about this modification? Regards - Jonathan Lu From luchsh at linux.vnet.ibm.com Wed Nov 2 09:01:25 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 02 Nov 2011 17:01:25 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB105D1.9020401@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> Message-ID: <4EB106E5.9060706@linux.vnet.ibm.com> On 11/02/2011 04:56 PM, Jonathan Lu wrote: > Hi core-libs-dev, > > In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line > 626, I found that the scope of "#ifdef __solaris__" might be too > narrow, since it also works for some kind of OS which I'm currently > working on, such as AIX. > So I suggest to just remove the '#ifdef __solaris__' and leave the > "#else" to accommodate more conditions, see attachment 'patch.diff'. I > think this may enhance the cross-platform ability, any ideas about > this modification? > > Regards > - Jonathan Lu I'm not sure why the attachment got filtered, here paste it to the mail content directly. diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 2011 -0700 +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 2011 +0800 @@ -626,10 +626,8 @@ #ifdef __linux__ if (tz == NULL) { #else -#ifdef __solaris__ if (tz == NULL || *tz == '\0') { #endif -#endif tz = getPlatformTimeZoneID(); freetz = tz; } Regards - Jonathan Lu From sean.coffey at oracle.com Wed Nov 2 09:18:17 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 02 Nov 2011 09:18:17 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB0E4C0.1040804@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> <4EAFC042.5080907@oracle.com> <4EB0E4C0.1040804@oracle.com> Message-ID: <4EB10AD9.9070304@oracle.com> On 02/11/2011 06:35, Alan Bateman wrote: > On 01/11/2011 09:47, Se?n Coffey wrote: >> : >> >> Are you referring to the parent.close() call ? If otherParents is >> null, then we only have one reference to this FileDesriptor - i.e the >> Stream that has called close(). > It's parent.close() that I'm wondering about. Suppose p1 is the > parent, p2 is in otherParents. If p2.close is invoked then it looks > like p1's close method will not be invoked, leaving p1 open and the > underlying file descriptor closed. The parent gets added to the ArrayList when that ArrayList needs to be set up (more than 1 referent) so this shouldn't be a problem. When the ArrayList (otherParents) is non-null a close will be called on the stream that initiated the close operation (through recursion) - that should be a no-op at that stage though. (closed == true) regards, Sean. > >> >> Any exception from releaser.close() becomes the main exception if one >> is seen there. Any exceptions from the earlier closes are then added >> as suppressed. I've run some tests on this and it looked to work as >> expected. (stack trace below) > In this example then the IOException appears to be thrown suppressing > one exception. That suppression exception in turn suppresses two > others. I had expected that the primary IOException would have > suppressed three exceptions. As I said, in practical terms this is > much of a concern, just pointing out that it's not exactly as expected. > >> I used hg rm/add. I guess hg mv would have worked too. > You need to use hg mv so that the history can be followed. Also webrev > handles it, at least before you create the changeset, so that you can > easily see the changes. > > -Alan. From Alan.Bateman at oracle.com Wed Nov 2 09:47:50 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Nov 2011 09:47:50 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EB086BB.3050608@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> Message-ID: <4EB111C6.8000008@oracle.com> On 01/11/2011 23:54, David Holmes wrote: > > This fix seems inconsistent with how this non-String problem is > handled elsewhere. It is, but (for whatever reason) is specified to return "the previous string value of the system property" whereas Properties.getProperty is specified to return "the value in this property list with the specified key value". Given that System.clearProperty has always been broken then there may be an opportunity to change it so that it is consistent and returns null. I also think Properties.getProperty could be clearer as it doesn't appear to specify that it returns null when the value isn't of type String. Darryl - just a couple of comments on the test - as it doesn't clean up after itself then it will need to run in its own VM to ensure that it doesn't cause problems for other tests that run subsequently in the same VM (@run main/othervm ClearProperty). Another nit with the test is that it doesn't check the return value of System.clearProperty. Another comment is that it doesn't need to catch CCE as the test will fail anyway if thrown. Also it would be nice to separate the test comment from the comment block with the jtreg tags so that it's consistent with other tests (alternatively just expand the wording in the @summary tag). -Alan. From Alan.Bateman at oracle.com Wed Nov 2 09:49:32 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Nov 2011 09:49:32 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB10AD9.9070304@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> <4EAFC042.5080907@oracle.com> <4EB0E4C0.1040804@oracle.com> <4EB10AD9.9070304@oracle.com> Message-ID: <4EB1122C.1050102@oracle.com> On 02/11/2011 09:18, Se?n Coffey wrote: > > The parent gets added to the ArrayList when that ArrayList needs to be > set up (more than 1 referent) so this shouldn't be a problem. When the > ArrayList (otherParents) is non-null a close will be called on the > stream that initiated the close operation (through recursion) - that > should be a no-op at that stage though. (closed == true) Okay, I see it although it is a bit strange to have two references to the original parent. -Alan. From david.holmes at oracle.com Wed Nov 2 11:00:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 02 Nov 2011 21:00:14 +1000 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB106E5.9060706@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> Message-ID: <4EB122BE.5090302@oracle.com> On 2/11/2011 7:01 PM, Jonathan Lu wrote: > On 11/02/2011 04:56 PM, Jonathan Lu wrote: >> Hi core-libs-dev, >> >> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line >> 626, I found that the scope of "#ifdef __solaris__" might be too >> narrow, since it also works for some kind of OS which I'm currently >> working on, such as AIX. >> So I suggest to just remove the '#ifdef __solaris__' and leave the >> "#else" to accommodate more conditions, see attachment 'patch.diff'. I >> think this may enhance the cross-platform ability, any ideas about >> this modification? >> >> Regards >> - Jonathan Lu > I'm not sure why the attachment got filtered, here paste it to the mail > content directly. > > diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c > --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 > 2011 -0700 > +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 > 2011 +0800 > @@ -626,10 +626,8 @@ > #ifdef __linux__ > if (tz == NULL) { > #else > -#ifdef __solaris__ > if (tz == NULL || *tz == '\0') { > #endif > -#endif > tz = getPlatformTimeZoneID(); > freetz = tz; > } I'm unclear why any of that code needs to be platform specific - is an empty TZ string somehow valid on linux? I would have thought the following would be platform neutral: if (tz == NULL || *tz == '\0') { tz = getPlatformTimeZoneID(); freetz = tz; } David ----- > Regards > - Jonathan Lu From luchsh at linux.vnet.ibm.com Wed Nov 2 11:39:32 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 02 Nov 2011 19:39:32 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB122BE.5090302@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> Message-ID: <4EB12BF4.9010805@linux.vnet.ibm.com> On 11/02/2011 07:00 PM, David Holmes wrote: > On 2/11/2011 7:01 PM, Jonathan Lu wrote: >> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>> Hi core-libs-dev, >>> >>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line >>> 626, I found that the scope of "#ifdef __solaris__" might be too >>> narrow, since it also works for some kind of OS which I'm currently >>> working on, such as AIX. >>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>> "#else" to accommodate more conditions, see attachment 'patch.diff'. I >>> think this may enhance the cross-platform ability, any ideas about >>> this modification? >>> >>> Regards >>> - Jonathan Lu >> I'm not sure why the attachment got filtered, here paste it to the mail >> content directly. >> >> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >> 2011 -0700 >> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >> 2011 +0800 >> @@ -626,10 +626,8 @@ >> #ifdef __linux__ >> if (tz == NULL) { >> #else >> -#ifdef __solaris__ >> if (tz == NULL || *tz == '\0') { >> #endif >> -#endif >> tz = getPlatformTimeZoneID(); >> freetz = tz; >> } > > I'm unclear why any of that code needs to be platform specific - is an > empty TZ string somehow valid on linux? I would have thought the > following would be platform neutral: > > if (tz == NULL || *tz == '\0') { > tz = getPlatformTimeZoneID(); > freetz = tz; > } > Hi David, getenv("TZ") returns NULL when TZ environment variable is not set at all and returns '\0' when TZ was exported as empty string. After more checking for both cases, I agree with you, nothing useful can be retrieved from that environment variable. So I changed the patch to this, diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 2011 -0700 +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 2011 +0800 @@ -623,13 +623,7 @@ tz = getenv("TZ"); -#ifdef __linux__ - if (tz == NULL) { -#else -#ifdef __solaris__ if (tz == NULL || *tz == '\0') { -#endif -#endif tz = getPlatformTimeZoneID(); freetz = tz; } > David > ----- > >> Regards >> - Jonathan Lu Regards - Jonathan From weijun.wang at oracle.com Wed Nov 2 11:46:26 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 02 Nov 2011 19:46:26 +0800 Subject: Code review request: 7107522: sun/misc/Version/Version.java fails because of its huge build number In-Reply-To: <17981356.1320234092694.JavaMail.sbladm@swsblss4-new> References: <17981356.1320234092694.JavaMail.sbladm@swsblss4-new> Message-ID: <4EB12D92.9040002@oracle.com> http://cr.openjdk.java.net/~weijun/7107522/webrev.00/ We must stay with the fact that a build number cannot exceed 255 while the system property "java.runtime.version" might show a bigger one. This fix only makes sure the test always passes. If you think there should be a more proper mail list to send to, please tell me. Thanks Max On 11/02/2011 07:41 PM, weijun.wang at oracle.com wrote: > *Change Request ID*: 7107522 > *Synopsis*: sun/misc/Version/Version.java fails because of its huge build number > > === *Description* ============================================================ > sun/misc/Version/Version.java always fails for nightly tests, because the build number from Hudson is like b9123. A normal build number should be less than 256, as shown in jvm.h: > > #define JDK_VERSION_BUILD(version) ((version& 0x000000FF)) From Alan.Bateman at oracle.com Wed Nov 2 14:08:29 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Nov 2011 14:08:29 +0000 Subject: Code review request: 7107522: sun/misc/Version/Version.java fails because of its huge build number In-Reply-To: <4EB12D92.9040002@oracle.com> References: <17981356.1320234092694.JavaMail.sbladm@swsblss4-new> <4EB12D92.9040002@oracle.com> Message-ID: <4EB14EDD.4020903@oracle.com> On 02/11/2011 11:46, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/7107522/webrev.00/ > > We must stay with the fact that a build number cannot exceed 255 while > the system property "java.runtime.version" might show a bigger one. > This fix only makes sure the test always passes. Max - I don't have time to look into the issue just now but I assume that if you use a debug or fastdebug build that it will fall over during startup (in other words, changing the test may just mask the issue with product builds). I'm sure Kelly or Mandy will be able to point you to the right place but I think that the major, minor, micro and build numbers are encoded into an int. Maybe this needs to be caught at build time or VersionInfo.initVersions needs to catch this at startup or maybe the jvm_version needs more space to accommodate longer build numbers - sorry I can't give you a specific suggestion without spending time digging into it. -Alan From masayoshi.okutsu at oracle.com Wed Nov 2 14:27:34 2011 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 02 Nov 2011 23:27:34 +0900 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB12BF4.9010805@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> Message-ID: <4EB15356.9080209@oracle.com> Hi Jonathan, IIRC, the difference came from some behavioral difference between the Linux and Solaris libc date-time functions and/or the date command, and TimeZone_md.c tries to follow the difference. But the code was written looooong ago. The difference may no longer exist. Thanks, Masayoshi On 11/2/2011 8:39 PM, Jonathan Lu wrote: > On 11/02/2011 07:00 PM, David Holmes wrote: >> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>> Hi core-libs-dev, >>>> >>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line >>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>> narrow, since it also works for some kind of OS which I'm currently >>>> working on, such as AIX. >>>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>>> "#else" to accommodate more conditions, see attachment 'patch.diff'. I >>>> think this may enhance the cross-platform ability, any ideas about >>>> this modification? >>>> >>>> Regards >>>> - Jonathan Lu >>> I'm not sure why the attachment got filtered, here paste it to the mail >>> content directly. >>> >>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >>> 2011 -0700 >>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >>> 2011 +0800 >>> @@ -626,10 +626,8 @@ >>> #ifdef __linux__ >>> if (tz == NULL) { >>> #else >>> -#ifdef __solaris__ >>> if (tz == NULL || *tz == '\0') { >>> #endif >>> -#endif >>> tz = getPlatformTimeZoneID(); >>> freetz = tz; >>> } >> >> I'm unclear why any of that code needs to be platform specific - is >> an empty TZ string somehow valid on linux? I would have thought the >> following would be platform neutral: >> >> if (tz == NULL || *tz == '\0') { >> tz = getPlatformTimeZoneID(); >> freetz = tz; >> } >> > Hi David, > > getenv("TZ") returns NULL when TZ environment variable is not set at > all and returns '\0' when TZ was exported as empty string. After more > checking for both cases, I agree with you, nothing useful can be > retrieved from that environment variable. > So I changed the patch to this, > > diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c > --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 > 10:32:47 2011 -0700 > +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 > 19:34:51 2011 +0800 > @@ -623,13 +623,7 @@ > > tz = getenv("TZ"); > > -#ifdef __linux__ > - if (tz == NULL) { > -#else > -#ifdef __solaris__ > if (tz == NULL || *tz == '\0') { > -#endif > -#endif > tz = getPlatformTimeZoneID(); > freetz = tz; > } > >> David >> ----- >> >>> Regards >>> - Jonathan Lu > Regards > > - Jonathan > From mandy.chung at oracle.com Wed Nov 2 18:01:22 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Nov 2011 11:01:22 -0700 Subject: Code review request: 7107522: sun/misc/Version/Version.java fails because of its huge build number In-Reply-To: <4EB12D92.9040002@oracle.com> References: <17981356.1320234092694.JavaMail.sbladm@swsblss4-new> <4EB12D92.9040002@oracle.com> Message-ID: <4EB18572.2060400@oracle.com> Hi Max, There is a bit of history here and I believe the right fix should be to fix the JDK_GetVersionInfo0 function in src/share/native/common/jdk_util.c to work with a large build number but treats any build number > 255 is an internal build. This test is intended to test the native interface between the VM and the libs to query the VM/JDK version. The HotSpot VM works with different versions of JDK and it uses this interface to determine what JDK version is and what capability it supports. The build number is more for information. It's expected to be used only during development of a feature and also the build number for promoted builds (not internal builds) when the VM and libs have to make a coordinated change while the VM has to continue to work with a JDK without the new libs change. Such interface was defined in the assumption of the number of promoted builds for a release < 256. For internal or engineering builds, it sets the build number to 0. Prior to JDK 7, the RE build version string is of this format: n.n.n[_uu[c]][-]-bxx For JDK 7, there were more than 99 builds and the format to take 3-digit builds. The RE hudson nightly build goes against the RE build version string convention. It sets the JDK_BUILD_NUMBER to "b9" + day of year. For example, January 1 is day 1 and the JDK_BUILD_NUMBER will be set to b9001. I think we should treat the RE hudson nightly build as an internal build and ignore the build number (or set it to 0). In jdk_util.c, it defines this variable: char build_number[4]; this should be fixed to work with any build number and set jdk_build_number only if it's < 255. Hope this helps. Mandy On 11/02/11 04:46, Weijun Wang wrote: > http://cr.openjdk.java.net/~weijun/7107522/webrev.00/ > > We must stay with the fact that a build number cannot exceed 255 while > the system property "java.runtime.version" might show a bigger one. > This fix only makes sure the test always passes. > > If you think there should be a more proper mail list to send to, > please tell me. > > Thanks > Max > > On 11/02/2011 07:41 PM, weijun.wang at oracle.com wrote: >> *Change Request ID*: 7107522 >> *Synopsis*: sun/misc/Version/Version.java fails because of its huge >> build number >> >> === *Description* >> ============================================================ >> sun/misc/Version/Version.java always fails for nightly tests, because >> the build number from Hudson is like b9123. A normal build number >> should be less than 256, as shown in jvm.h: >> >> #define JDK_VERSION_BUILD(version) ((version& 0x000000FF)) From david.holmes at oracle.com Wed Nov 2 19:59:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 03 Nov 2011 05:59:14 +1000 Subject: Code Review Request for 6578042 In-Reply-To: <4EB111C6.8000008@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> Message-ID: <4EB1A112.3070102@oracle.com> Hi Alan, On 2/11/2011 7:47 PM, Alan Bateman wrote: > On 01/11/2011 23:54, David Holmes wrote: >> >> This fix seems inconsistent with how this non-String problem is >> handled elsewhere. > It is, but (for whatever reason) is specified to return "the previous > string value of the system property" whereas Properties.getProperty is > specified to return "the value in this property list with the specified > key value". I'm not seeing a distinction in those two statements. Both expect to return the property value for a given key; both assume a valid value is a String. clearProperty throws ClassCastException if the assumption doesn't hold; getProperty instead returns null. > Given that System.clearProperty has always been broken then > there may be an opportunity to change it so that it is consistent and > returns null. I'm not even sure this is broken. If you put something other than a String in a Property then you get what you deserve. ClassCastException seems quite reasonable to me. But if we must get rid of the exception then getProperty has established the pattern. I don't think calling toString on an arbitrary object is the right way to deal with this. >I also think Properties.getProperty could be clearer as it > doesn't appear to specify that it returns null when the value isn't of > type String. There's an assumption that everyone reads and obeys the directive to not use the Hashtable methods that allow you to insert non-strings. Cheers, David ----- > > Darryl - just a couple of comments on the test - as it doesn't clean up > after itself then it will need to run in its own VM to ensure that it > doesn't cause problems for other tests that run subsequently in the same > VM (@run main/othervm ClearProperty). Another nit with the test is that > it doesn't check the return value of System.clearProperty. Another > comment is that it doesn't need to catch CCE as the test will fail > anyway if thrown. Also it would be nice to separate the test comment > from the comment block with the jtreg tags so that it's consistent with > other tests (alternatively just expand the wording in the @summary tag). > > -Alan. From xueming.shen at oracle.com Thu Nov 3 00:18:16 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 02 Nov 2011 17:18:16 -0700 Subject: performance updates to jar and zip In-Reply-To: <1320106285.80954.YahooMailNeo@web86608.mail.ird.yahoo.com> References: <1319151335.40809.YahooMailNeo@web86607.mail.ird.yahoo.com> <4EA8959D.7030202@oracle.com> <1319756870.73164.YahooMailNeo@web86601.mail.ird.yahoo.com> <4EAF11E2.7000008@oracle.com> <1320106285.80954.YahooMailNeo@web86608.mail.ird.yahoo.com> Message-ID: <4EB1DDC8.8030408@oracle.com> On 10/31/2011 5:11 PM, Mike Skells wrote: > > (2) Iti is true that this is not a performance gain by code > improvement, but it is a performnce gain by specification. > The same arguement applies to allowing a Zip Compression of 1 rather > than the default. As for the spec, all I have seen is that it should > provide the date is available. > I am not that fussed if we include this in another section and I that > all specification changes need to be considered seperately, as long as > it is not lost > > I ran you test and I did not see more than 15% difference in the > scanning with jav2DosTime includes/excluded. Minimal time in profiler > reported as well > Running the same time on the same files via the sample improved app > that you supplied I see 16% of the time spent in javaToDosTime > > Could this be a micro-benchmark issue? (aqnd/or a profiling issue) > In the benchmarks that I have for the full jar app I see usually 5-10% > total time reduction in the tests that are CPU bound > I don't think java2DosTime can take 5-10% of the total time of jarring 25k files with a total of 50M+ bytes. A straight N iteration of it should give us some idea whether not it it can take that much of time. I finally got your patch "worked" on JDK8 for Z2/Z3 case, by commenting out line#112 of FileScanning.java http://cr.openjdk.java.net/~sherman/mtjar/webrev/src/share/classes/sun/tools/jar/FileScanning.java.html It appears startPath.relativize() returns something (../) you might not expect to work on. Observation: (1) cf6Z2 works, but slower than Z3 @flicker-vm2:/tmp/sherman/test]../mtjar2-linux/bin/java Jar cf6Z2 rt.jar rtjar Jar TotalTime:3402 Jar TotalTime:3363 Jar TotalTime:3460 Jar TotalTime:3468 Jar TotalTime:3594 (2) Z3 is faster but it creates a 0-length rt.jar, a bug somewhere [@flicker-vm2:/tmp/sherman/test]../mtjar2-linux/bin/java Jar cf6Z3 rt.jar rtjar Jar TotalTime:2921 Jar TotalTime:2974 Jar TotalTime:2998 Jar TotalTime:2856 Jar TotalTime:2883 (3) -D such as cf6DZ2 cf6DZ3 does not appear to have any significant/meaningful image to the overall time spent. (4) it takes about 7xxx ms for the same jar by using a un-touched jdk8 jar [@flicker-vm2:/tmp/sherman/test]../orig-linux/bin/java Jar cf rt.jar rtjar Jar TotalTime:7472 Jar TotalTime:7298 Jar TotalTime:7979 Jar TotalTime:7599 (5) Z4, 5 still throws exception as showed below. I'm yet to dig into the code to see what went wrong. [@flicker-vm2:/tmp/sherman/test]../mtjar2-linux/bin/java Jar cf6Z4 rt.jar rtjar Warmup:rtjar...done java.lang.NullPointerException at java.util.zip.ZipChannelWriter.rewriteReserved(ZipChannelWriter.java:211) at java.util.zip.AbstractRewritingZipWriter.writeMissingHeaderInfo(AbstractRewritingZipWriter.java:44) at java.util.zip.AbstractZipWriter.startWritingDeflator(AbstractZipWriter.java:611) at java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:347) at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at sun.tools.jar.Main.waitFor(Main.java:810) at sun.tools.jar.Main.run(Main.java:679) at Jar.main(Jar.java:39) Caused by: java.lang.NullPointerException at java.util.zip.ZipChannelWriter.rewriteReserved(ZipChannelWriter.java:211) at java.util.zip.AbstractRewritingZipWriter.writeMissingHeaderInfo(AbstractRewritingZipWriter.java:44) at java.util.zip.AbstractZipWriter.startWritingDeflator(AbstractZipWriter.java:611) at java.util.zip.AbstractZipWriter.writeWithResource(AbstractZipWriter.java:347) at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:273) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) java.io.IOException: java.lang.InterruptedException at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:289) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:410) at sun.tools.jar.Main$ZipOutputLoader2File.call(Main.java:350) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.InterruptedException at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2038) at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:374) at java.util.zip.DefaultZipResourcePool.acquire(DefaultZipResourcePool.java:50) at java.util.zip.DefaultZipResourcePool.exchange(DefaultZipResourcePool.java:114) at java.util.zip.AbstractZipWriter.writeAll(AbstractZipWriter.java:272) From weijun.wang at oracle.com Thu Nov 3 04:09:52 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 03 Nov 2011 12:09:52 +0800 Subject: Code review request: 7107522: sun/misc/Version/Version.java fails because of its huge build number In-Reply-To: <4EB18572.2060400@oracle.com> References: <17981356.1320234092694.JavaMail.sbladm@swsblss4-new> <4EB12D92.9040002@oracle.com> <4EB18572.2060400@oracle.com> Message-ID: <4EB21410.7030901@oracle.com> Updated webrev: http://cr.openjdk.java.net/~weijun/7107522/webrev.01/ -Max On 11/03/2011 02:01 AM, Mandy Chung wrote: > Hi Max, > > There is a bit of history here and I believe the right fix should be to > fix the JDK_GetVersionInfo0 function in > src/share/native/common/jdk_util.c to work with a large build number but > treats any build number > 255 is an internal build. > > This test is intended to test the native interface between the VM and > the libs to query the VM/JDK version. The HotSpot VM works with > different versions of JDK and it uses this interface to determine what > JDK version is and what capability it supports. The build number is more > for information. It's expected to be used only during development of a > feature and also the build number for promoted builds (not internal > builds) when the VM and libs have to make a coordinated change while the > VM has to continue to work with a JDK without the new libs change. Such > interface was defined in the assumption of the number of promoted builds > for a release < 256. For internal or engineering builds, it sets the > build number to 0. > > Prior to JDK 7, the RE build version string is of this format: > n.n.n[_uu[c]][-]-bxx > > For JDK 7, there were more than 99 builds and the format to take 3-digit > builds. > > The RE hudson nightly build goes against the RE build version string > convention. It sets the JDK_BUILD_NUMBER to "b9" + day of year. For > example, January 1 is day 1 and the JDK_BUILD_NUMBER will be set to b9001. > > I think we should treat the RE hudson nightly build as an internal build > and ignore the build number (or set it to 0). > > In jdk_util.c, it defines this variable: > char build_number[4]; > > this should be fixed to work with any build number and set > jdk_build_number only if it's < 255. > > Hope this helps. > Mandy > > On 11/02/11 04:46, Weijun Wang wrote: >> http://cr.openjdk.java.net/~weijun/7107522/webrev.00/ >> >> We must stay with the fact that a build number cannot exceed 255 while >> the system property "java.runtime.version" might show a bigger one. >> This fix only makes sure the test always passes. >> >> If you think there should be a more proper mail list to send to, >> please tell me. >> >> Thanks >> Max >> >> On 11/02/2011 07:41 PM, weijun.wang at oracle.com wrote: >>> *Change Request ID*: 7107522 >>> *Synopsis*: sun/misc/Version/Version.java fails because of its huge >>> build number >>> >>> === *Description* >>> ============================================================ >>> sun/misc/Version/Version.java always fails for nightly tests, because >>> the build number from Hudson is like b9123. A normal build number >>> should be less than 256, as shown in jvm.h: >>> >>> #define JDK_VERSION_BUILD(version) ((version& 0x000000FF)) > From luchsh at linux.vnet.ibm.com Thu Nov 3 07:16:37 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 03 Nov 2011 15:16:37 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB15356.9080209@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> Message-ID: <4EB23FD5.60108@linux.vnet.ibm.com> Hi Masayoshi, I did find some references about date-time related functions / TZ variables on Linux but got only a few about Solaris, so could not see any differences between those two platforms about the changes described in my patch. Have you got any links or references about these differences? I'm interested in it and may update the patch again after reading them. Thanks a lot! - Jonathan On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: > Hi Jonathan, > > IIRC, the difference came from some behavioral difference between the > Linux and Solaris libc date-time functions and/or the date command, > and TimeZone_md.c tries to follow the difference. But the code was > written looooong ago. The difference may no longer exist. > > Thanks, > Masayoshi > > On 11/2/2011 8:39 PM, Jonathan Lu wrote: >> On 11/02/2011 07:00 PM, David Holmes wrote: >>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>> Hi core-libs-dev, >>>>> >>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line >>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>> narrow, since it also works for some kind of OS which I'm currently >>>>> working on, such as AIX. >>>>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>>>> "#else" to accommodate more conditions, see attachment >>>>> 'patch.diff'. I >>>>> think this may enhance the cross-platform ability, any ideas about >>>>> this modification? >>>>> >>>>> Regards >>>>> - Jonathan Lu >>>> I'm not sure why the attachment got filtered, here paste it to the >>>> mail >>>> content directly. >>>> >>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >>>> 2011 -0700 >>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >>>> 2011 +0800 >>>> @@ -626,10 +626,8 @@ >>>> #ifdef __linux__ >>>> if (tz == NULL) { >>>> #else >>>> -#ifdef __solaris__ >>>> if (tz == NULL || *tz == '\0') { >>>> #endif >>>> -#endif >>>> tz = getPlatformTimeZoneID(); >>>> freetz = tz; >>>> } >>> >>> I'm unclear why any of that code needs to be platform specific - is >>> an empty TZ string somehow valid on linux? I would have thought the >>> following would be platform neutral: >>> >>> if (tz == NULL || *tz == '\0') { >>> tz = getPlatformTimeZoneID(); >>> freetz = tz; >>> } >>> >> Hi David, >> >> getenv("TZ") returns NULL when TZ environment variable is not set at >> all and returns '\0' when TZ was exported as empty string. After more >> checking for both cases, I agree with you, nothing useful can be >> retrieved from that environment variable. >> So I changed the patch to this, >> >> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >> 10:32:47 2011 -0700 >> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 >> 19:34:51 2011 +0800 >> @@ -623,13 +623,7 @@ >> >> tz = getenv("TZ"); >> >> -#ifdef __linux__ >> - if (tz == NULL) { >> -#else >> -#ifdef __solaris__ >> if (tz == NULL || *tz == '\0') { >> -#endif >> -#endif >> tz = getPlatformTimeZoneID(); >> freetz = tz; >> } >> >>> David >>> ----- >>> >>>> Regards >>>> - Jonathan Lu >> Regards >> >> - Jonathan >> From mike.duigou at oracle.com Thu Nov 3 21:00:24 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 03 Nov 2011 21:00:24 +0000 Subject: hg: jdk8/tl/jdk: 4533691: Add Collections.emptySortedSet() Message-ID: <20111103210053.E80D247224@hg.openjdk.java.net> Changeset: 2f2f56ac8b82 Author: mduigou Date: 2011-11-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f2f56ac8b82 4533691: Add Collections.emptySortedSet() Reviewed-by: mduigou, alanb, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/util/Collections.java + test/java/util/Collections/EmptySortedSet.java From david.holmes at oracle.com Fri Nov 4 00:40:45 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Nov 2011 10:40:45 +1000 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EADF138.30604@oracle.com> References: <4EAB3049.8040409@oracle.com> <4EADF138.30604@oracle.com> Message-ID: <4EB3348D.9070405@oracle.com> Mike, I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. David On 31/10/2011 10:52 AM, David Holmes wrote: > Darryl, > > On 29/10/2011 8:44 AM, Darryl Mocek wrote: >> Hello. Please review this patch to add empty sorted set to the >> Collections class. Test case provided. >> >> Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ > > This was an RFE from 2001 - pre-generics. I don't think it makes sense > to add to the pre-generics pollution by defining EMPTY_SORTED_SET. > >> Additional Notes to Reviewers: >> The sets resulting from tailSet() headSet() and subSet() normally >> include the range which was used to create them. Using these methods >> with emptySortedSet() does not currently set a range on the resulting >> sets. > > What is the range on an empty set? > > David > ----- > >> Thanks, >> Darryl From masayoshi.okutsu at oracle.com Fri Nov 4 04:13:00 2011 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 04 Nov 2011 13:13:00 +0900 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB23FD5.60108@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> Message-ID: <4EB3664C.1050908@oracle.com> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu 10.03. The difference still exists. Solaris 10: $ unset TZ $ date Fri Nov 4 13:04:45 JST 2011 $ TZ="" date Fri Nov 4 13:04:53 JST 2011 Ubuntu 10.04: $ unset TZ $ date Fri Nov 4 13:05:50 JST 2011 $ TZ="" date Fri Nov 4 04:05:55 UTC 2011 When the TZ value is an empty string, Ubuntu uses UTC while Solaris still looks up the system default. Thanks, Masayoshi On 11/3/2011 4:16 PM, Jonathan Lu wrote: > Hi Masayoshi, > > I did find some references about date-time related functions / TZ > variables on Linux but got only a few about Solaris, so could not see > any differences between those two platforms about the changes > described in my patch. Have you got any links or references about > these differences? I'm interested in it and may update the patch again > after reading them. > > Thanks a lot! > - Jonathan > > On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >> Hi Jonathan, >> >> IIRC, the difference came from some behavioral difference between the >> Linux and Solaris libc date-time functions and/or the date command, >> and TimeZone_md.c tries to follow the difference. But the code was >> written looooong ago. The difference may no longer exist. >> >> Thanks, >> Masayoshi >> >> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>> Hi core-libs-dev, >>>>>> >>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>> line >>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>> narrow, since it also works for some kind of OS which I'm currently >>>>>> working on, such as AIX. >>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>>>>> "#else" to accommodate more conditions, see attachment >>>>>> 'patch.diff'. I >>>>>> think this may enhance the cross-platform ability, any ideas about >>>>>> this modification? >>>>>> >>>>>> Regards >>>>>> - Jonathan Lu >>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>> mail >>>>> content directly. >>>>> >>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >>>>> 2011 -0700 >>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >>>>> 2011 +0800 >>>>> @@ -626,10 +626,8 @@ >>>>> #ifdef __linux__ >>>>> if (tz == NULL) { >>>>> #else >>>>> -#ifdef __solaris__ >>>>> if (tz == NULL || *tz == '\0') { >>>>> #endif >>>>> -#endif >>>>> tz = getPlatformTimeZoneID(); >>>>> freetz = tz; >>>>> } >>>> >>>> I'm unclear why any of that code needs to be platform specific - is >>>> an empty TZ string somehow valid on linux? I would have thought the >>>> following would be platform neutral: >>>> >>>> if (tz == NULL || *tz == '\0') { >>>> tz = getPlatformTimeZoneID(); >>>> freetz = tz; >>>> } >>>> >>> Hi David, >>> >>> getenv("TZ") returns NULL when TZ environment variable is not set at >>> all and returns '\0' when TZ was exported as empty string. After >>> more checking for both cases, I agree with you, nothing useful can >>> be retrieved from that environment variable. >>> So I changed the patch to this, >>> >>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>> 10:32:47 2011 -0700 >>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 >>> 19:34:51 2011 +0800 >>> @@ -623,13 +623,7 @@ >>> >>> tz = getenv("TZ"); >>> >>> -#ifdef __linux__ >>> - if (tz == NULL) { >>> -#else >>> -#ifdef __solaris__ >>> if (tz == NULL || *tz == '\0') { >>> -#endif >>> -#endif >>> tz = getPlatformTimeZoneID(); >>> freetz = tz; >>> } >>> >>>> David >>>> ----- >>>> >>>>> Regards >>>>> - Jonathan Lu >>> Regards >>> >>> - Jonathan >>> > From david.holmes at oracle.com Fri Nov 4 04:53:39 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Nov 2011 14:53:39 +1000 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB3664C.1050908@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> Message-ID: <4EB36FD3.3030306@oracle.com> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: > Probably the difference isn't documented. I tried Solaris 10 and Ubuntu > 10.03. The difference still exists. > > Solaris 10: > $ unset TZ > $ date > Fri Nov 4 13:04:45 JST 2011 > $ TZ="" date > Fri Nov 4 13:04:53 JST 2011 > > Ubuntu 10.04: > $ unset TZ > $ date > Fri Nov 4 13:05:50 JST 2011 > $ TZ="" date > Fri Nov 4 04:05:55 UTC 2011 > > When the TZ value is an empty string, Ubuntu uses UTC while Solaris > still looks up the system default. I have to take back my comment regarding this not seeming to be platform specific code - it is highly platform specific! It seems that on Linux we are happy to report a TZ of "" but not so on Solaris. I presume this is an attempt to keep Java's use of TZ consistent with how other apps handle it on that platform. (environ(5) gives a little insight on Solaris as to how TZ is used.) So the key thing here is to not disturb the existing behaviour on either linux or Solaris - which suggests the original patch. That said I'm not convinced - given this is so platform specific - that simply treating non-linux the same as Solaris is a reasonable thing to do. I think it would be useful to see what the BSD/OSX port(s) had to do with this code - if anything. David ----- > Thanks, > Masayoshi > > On 11/3/2011 4:16 PM, Jonathan Lu wrote: >> Hi Masayoshi, >> >> I did find some references about date-time related functions / TZ >> variables on Linux but got only a few about Solaris, so could not see >> any differences between those two platforms about the changes >> described in my patch. Have you got any links or references about >> these differences? I'm interested in it and may update the patch again >> after reading them. >> >> Thanks a lot! >> - Jonathan >> >> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>> Hi Jonathan, >>> >>> IIRC, the difference came from some behavioral difference between the >>> Linux and Solaris libc date-time functions and/or the date command, >>> and TimeZone_md.c tries to follow the difference. But the code was >>> written looooong ago. The difference may no longer exist. >>> >>> Thanks, >>> Masayoshi >>> >>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>> Hi core-libs-dev, >>>>>>> >>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>> line >>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>> narrow, since it also works for some kind of OS which I'm currently >>>>>>> working on, such as AIX. >>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>> 'patch.diff'. I >>>>>>> think this may enhance the cross-platform ability, any ideas about >>>>>>> this modification? >>>>>>> >>>>>>> Regards >>>>>>> - Jonathan Lu >>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>> mail >>>>>> content directly. >>>>>> >>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >>>>>> 2011 -0700 >>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >>>>>> 2011 +0800 >>>>>> @@ -626,10 +626,8 @@ >>>>>> #ifdef __linux__ >>>>>> if (tz == NULL) { >>>>>> #else >>>>>> -#ifdef __solaris__ >>>>>> if (tz == NULL || *tz == '\0') { >>>>>> #endif >>>>>> -#endif >>>>>> tz = getPlatformTimeZoneID(); >>>>>> freetz = tz; >>>>>> } >>>>> >>>>> I'm unclear why any of that code needs to be platform specific - is >>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>> following would be platform neutral: >>>>> >>>>> if (tz == NULL || *tz == '\0') { >>>>> tz = getPlatformTimeZoneID(); >>>>> freetz = tz; >>>>> } >>>>> >>>> Hi David, >>>> >>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>> all and returns '\0' when TZ was exported as empty string. After >>>> more checking for both cases, I agree with you, nothing useful can >>>> be retrieved from that environment variable. >>>> So I changed the patch to this, >>>> >>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>> 2011 -0700 >>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>> 2011 +0800 >>>> @@ -623,13 +623,7 @@ >>>> >>>> tz = getenv("TZ"); >>>> >>>> -#ifdef __linux__ >>>> - if (tz == NULL) { >>>> -#else >>>> -#ifdef __solaris__ >>>> if (tz == NULL || *tz == '\0') { >>>> -#endif >>>> -#endif >>>> tz = getPlatformTimeZoneID(); >>>> freetz = tz; >>>> } >>>> >>>>> David >>>>> ----- >>>>> >>>>>> Regards >>>>>> - Jonathan Lu >>>> Regards >>>> >>>> - Jonathan >>>> >> From david.holmes at oracle.com Fri Nov 4 05:26:26 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 04 Nov 2011 15:26:26 +1000 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB36FD3.3030306@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> Message-ID: <4EB37782.9010507@oracle.com> On 4/11/2011 2:53 PM, David Holmes wrote: > On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >> 10.03. The difference still exists. >> >> Solaris 10: >> $ unset TZ >> $ date >> Fri Nov 4 13:04:45 JST 2011 >> $ TZ="" date >> Fri Nov 4 13:04:53 JST 2011 >> >> Ubuntu 10.04: >> $ unset TZ >> $ date >> Fri Nov 4 13:05:50 JST 2011 >> $ TZ="" date >> Fri Nov 4 04:05:55 UTC 2011 >> >> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >> still looks up the system default. > > I have to take back my comment regarding this not seeming to be platform > specific code - it is highly platform specific! It seems that on Linux > we are happy to report a TZ of "" but not so on Solaris. I presume this > is an attempt to keep Java's use of TZ consistent with how other apps > handle it on that platform. (environ(5) gives a little insight on > Solaris as to how TZ is used.) > > So the key thing here is to not disturb the existing behaviour on either > linux or Solaris - which suggests the original patch. That said I'm not > convinced - given this is so platform specific - that simply treating > non-linux the same as Solaris is a reasonable thing to do. I think it > would be useful to see what the BSD/OSX port(s) had to do with this code > - if anything. To answer my own queries BSD/OSX does 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) 512 if (tz == NULL) { 513 #else 514 #ifdef __solaris__ 515 if (tz == NULL || *tz == '\0') { 516 #endif 517 #endif so the suggested patch would at least not interfere. Anyway this needs input from other core-libs folk. I didn't intend to get quite so heavily involved. ;-) David ----- > David > ----- > > >> Thanks, >> Masayoshi >> >> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>> Hi Masayoshi, >>> >>> I did find some references about date-time related functions / TZ >>> variables on Linux but got only a few about Solaris, so could not see >>> any differences between those two platforms about the changes >>> described in my patch. Have you got any links or references about >>> these differences? I'm interested in it and may update the patch again >>> after reading them. >>> >>> Thanks a lot! >>> - Jonathan >>> >>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>> Hi Jonathan, >>>> >>>> IIRC, the difference came from some behavioral difference between the >>>> Linux and Solaris libc date-time functions and/or the date command, >>>> and TimeZone_md.c tries to follow the difference. But the code was >>>> written looooong ago. The difference may no longer exist. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>> Hi core-libs-dev, >>>>>>>> >>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>> line >>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>> narrow, since it also works for some kind of OS which I'm currently >>>>>>>> working on, such as AIX. >>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave the >>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>> 'patch.diff'. I >>>>>>>> think this may enhance the cross-platform ability, any ideas about >>>>>>>> this modification? >>>>>>>> >>>>>>>> Regards >>>>>>>> - Jonathan Lu >>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>> mail >>>>>>> content directly. >>>>>>> >>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 19:06:53 >>>>>>> 2011 -0700 >>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 13:43:47 >>>>>>> 2011 +0800 >>>>>>> @@ -626,10 +626,8 @@ >>>>>>> #ifdef __linux__ >>>>>>> if (tz == NULL) { >>>>>>> #else >>>>>>> -#ifdef __solaris__ >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> #endif >>>>>>> -#endif >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>> >>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>> following would be platform neutral: >>>>>> >>>>>> if (tz == NULL || *tz == '\0') { >>>>>> tz = getPlatformTimeZoneID(); >>>>>> freetz = tz; >>>>>> } >>>>>> >>>>> Hi David, >>>>> >>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>> all and returns '\0' when TZ was exported as empty string. After >>>>> more checking for both cases, I agree with you, nothing useful can >>>>> be retrieved from that environment variable. >>>>> So I changed the patch to this, >>>>> >>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>> 2011 -0700 >>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>> 2011 +0800 >>>>> @@ -623,13 +623,7 @@ >>>>> >>>>> tz = getenv("TZ"); >>>>> >>>>> -#ifdef __linux__ >>>>> - if (tz == NULL) { >>>>> -#else >>>>> -#ifdef __solaris__ >>>>> if (tz == NULL || *tz == '\0') { >>>>> -#endif >>>>> -#endif >>>>> tz = getPlatformTimeZoneID(); >>>>> freetz = tz; >>>>> } >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Regards >>>>>>> - Jonathan Lu >>>>> Regards >>>>> >>>>> - Jonathan >>>>> >>> From heiko.wagner at apis.de Fri Nov 4 09:58:10 2011 From: heiko.wagner at apis.de (Heiko Wagner) Date: Fri, 4 Nov 2011 10:58:10 +0100 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String) in JDK 6&7 Message-ID: I hope this is the right list to post this. I encounter some behaviour, that I am not sure whether this is correct. When invoking ResourceBundle.getBundle("com.some.Bundle") I get a ArrayIndexOutOfBoundsException. This is caused by the fact that the ResourceBundle class tries to determine the actual ClassLoader using the getLoader() method, via accessing the hardcoded stack offset 2, which works when the getBundle() method is callen from Java, but in my case I invoke this method using JNI and the stack layout is different, so causing the exception. I know this code has been this way a for a long time, but I still get a beed feeling when the code relies on some hard code offsets in the call stack and I see no reason why invoking the ResourceBundle methods via JNI should be considered "illegal". Despite the trivial workaround for this problem. i.e. explicitly specify the ClassLoader with getBundle(String, Locale, ClassLoader), I would like to hear your opinion on this. Regards, Heiko From tom.hawtin at oracle.com Fri Nov 4 11:26:39 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 04 Nov 2011 11:26:39 +0000 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String) in JDK 6&7 In-Reply-To: References: Message-ID: <4EB3CBEF.2040404@oracle.com> On 04/11/11 09:58, Heiko Wagner wrote: > This is caused by the fact that the ResourceBundle class tries to determine > the actual ClassLoader using the getLoader() method, via accessing the > hardcoded stack offset 2, which works when the getBundle() method is callen > from Java, but in my case I invoke this method using JNI and the stack > layout is different, so causing the exception. > > I know this code has been this way a for a long time, but I still get a beed > feeling when the code relies on some hard code offsets in the call stack and > I see no reason why invoking the ResourceBundle methods via JNI should be > considered "illegal". I'm not a JNI expert (you are calling from a thread known to the JVM, right?). However, getBundle is one of the magic methods listed in section 6 (6-4) of the Java Secure Coding Guidelines[1] that depend upon the immediate caller. If there isn't an immediate [Java] caller, that isn't going to work. Which ClassLoader would you want getBundle to use? Tom [1]http://www.oracle.com/technetwork/java/seccodeguide-139067.html#6-0 From heiko.wagner at apis.de Fri Nov 4 12:03:02 2011 From: heiko.wagner at apis.de (Heiko Wagner) Date: Fri, 4 Nov 2011 13:03:02 +0100 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <4EB3CBEF.2040404@oracle.com> Message-ID: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> Hi Tom, thanks for your reply. I am using JNI in a different,propably never designed to be used that way, kind of scenario. I use JNI to bring Java to a legacy Smalltalk based product[1]. The Smalltalk code does directly invoke the JNI calls from its own Smalltalk VM main thread. So the Java VM is not aware of the calling thread and has no call stack information. Currently, I am using ClassLoader.getSystemClassLoader(), which perfectly works for me. I have no idea if this makes sense in gerneal, but for me a MissingResourceBundleException in my use case, would be what I propably would have expected, instead of a ArrayIndexOutOfBoundsException, so maybe a additional size check on the call stack array size would make sense. P.S. Despite my hefty "abuse" of JNI, it overall still works very well. Regards, Heiko [1] http://vst.ensm-douai.fr/Esug2008Media/uploads/1/APIS_ESUG.pdf (Slide 12-19) >I'm not a JNI expert (you are calling from a thread known to the JVM, >right?). However, getBundle is one of the magic methods listed in >section 6 (6-4) of the Java Secure Coding Guidelines[1] that depend upon >the immediate caller. If there isn't an immediate [Java] caller, that >isn't going to work. Which ClassLoader would you want getBundle to use? > >Tom From maurizio.cimadamore at oracle.com Fri Nov 4 12:57:22 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 04 Nov 2011 12:57:22 +0000 Subject: hg: jdk8/tl/langtools: 7104201: Refactor DocCommentScanner Message-ID: <20111104125724.B49FB4723F@hg.openjdk.java.net> Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out From sean.coffey at oracle.com Fri Nov 4 13:08:41 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Fri, 04 Nov 2011 13:08:41 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB0E4C0.1040804@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> <4EAFC042.5080907@oracle.com> <4EB0E4C0.1040804@oracle.com> Message-ID: <4EB3E3D9.4050807@oracle.com> ok, so updated webrev at : http://cr.openjdk.java.net/~coffeys/webrev.7105952.2/ some minor modifications : * "closed" variable made private * hg mv instead of rm/add for testcase * testcase padded up some more. * comments changed to block style format in FileDescriptor. * some extra comments added to FileDescriptor to help read code I'll leave the javadoc changes for another bugID/CCC request. regards, Sean. On 02/11/11 06:35, Alan Bateman wrote: > On 01/11/2011 09:47, Se?n Coffey wrote: >> : >> >> Are you referring to the parent.close() call ? If otherParents is >> null, then we only have one reference to this FileDesriptor - i.e the >> Stream that has called close(). > It's parent.close() that I'm wondering about. Suppose p1 is the > parent, p2 is in otherParents. If p2.close is invoked then it looks > like p1's close method will not be invoked, leaving p1 open and the > underlying file descriptor closed. > >> >> Any exception from releaser.close() becomes the main exception if one >> is seen there. Any exceptions from the earlier closes are then added >> as suppressed. I've run some tests on this and it looked to work as >> expected. (stack trace below) > In this example then the IOException appears to be thrown suppressing > one exception. That suppression exception in turn suppresses two > others. I had expected that the primary IOException would have > suppressed three exceptions. As I said, in practical terms this is > much of a concern, just pointing out that it's not exactly as expected. > >> I used hg rm/add. I guess hg mv would have worked too. > You need to use hg mv so that the history can be followed. Also webrev > handles it, at least before you create the changeset, so that you can > easily see the changes. > > -Alan. From gary.adams at oracle.com Fri Nov 4 13:36:53 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 04 Nov 2011 09:36:53 -0400 Subject: Timing bugs Message-ID: <4EB3EA75.2050006@oracle.com> I've started to look at timing related bugs that have been open for a while, but have not had sufficient priority to make it to the top of the list of bugs to be fixed. Thought I'd start with some low hanging fruit with simple bug fixes. 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf This seems like a simply problem to avoid two calls to get the current time and to eliminated the time to process the print statement from the evaluation of the test elapsed time. Replacing this sequence ; System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); check(System.currentTimeMillis() - start < 500); with elapsed = System.currentTimeMillis() - start; System.out.printf("elapsed=%d%n", elapsed); check(elapsed < 500); I plan to test the fix on a 300MHz linux/arm device. I'll provide a proper webrev as soon as I have author rights confirmed. I'm looking for reviewer and a committer, once I get the fix tested locally. Thanks Gary Adams From gary.adams at oracle.com Fri Nov 4 15:52:01 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 04 Nov 2011 11:52:01 -0400 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EB3EA75.2050006@oracle.com> References: <4EB3EA75.2050006@oracle.com> Message-ID: <4EB40A21.2080105@oracle.com> I'm taking a look at some older timing based bugs that may cause problems on slower machines 6818464: TEST_BUG: Timeout values in several java/util tests are insufficient I'd like to split this bug into two, based on the example problems that are mentioned in the bug report. The first example in java/util/Timer/KillThread.java is a legitimate race condition. The code only will work correctly if the processing for the TimerTask schedules and fires the runnable within the hard coded 100 milliseconds. This can be fixed with a local variable to synchronize when the the second operation can be attempted. (Hard coded sleep times are rarely correct when dealing with slower devices.) In the second example the test instructions present a timeout to be enforced by the outer test harness. e.g. @run main/timeout=20 StoreDeadLock This type of test limit is easily addressed on slower machines using the test harness timefactor to scale the acceptable test run time. I'll attempt a simple fix for the KillThread case by replacing : Thread.sleep(100); with a simple loop do { Thread.sleep(100); } while (waiting); where the TimerTask runnable will clear the flag with "waiting = false " once it has been launched. From mike.duigou at oracle.com Fri Nov 4 16:29:09 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 4 Nov 2011 09:29:09 -0700 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EB3348D.9070405@oracle.com> References: <4EAB3049.8040409@oracle.com> <4EADF138.30604@oracle.com> <4EB3348D.9070405@oracle.com> Message-ID: On Nov 3 2011, at 17:40 , David Holmes wrote: > Mike, > > I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. I missed your question about the range on an empty set. My comments below. Removing EMPTY_SORTED_SET was the only other comment to my knowledge. Darryl adapted the patch and EMPTY_SORTED_SET was not part of the commit. Since the change was removal of a newly proposed field an additional review cycle wasn't thought to be necessary. Perhaps incorrectly? Mike > David > > On 31/10/2011 10:52 AM, David Holmes wrote: >> Darryl, >> >> On 29/10/2011 8:44 AM, Darryl Mocek wrote: >>> Hello. Please review this patch to add empty sorted set to the >>> Collections class. Test case provided. >>> >>> Webrev: http://cr.openjdk.java.net/~mduigou/4533691/1/webrev/ >> >> This was an RFE from 2001 - pre-generics. I don't think it makes sense >> to add to the pre-generics pollution by defining EMPTY_SORTED_SET. >> >>> Additional Notes to Reviewers: >>> The sets resulting from tailSet() headSet() and subSet() normally >>> include the range which was used to create them. Using these methods >>> with emptySortedSet() does not currently set a range on the resulting >>> sets. >> >> What is the range on an empty set? The results of Collections.emptySortedSet() will behave differently than Collections.unmodifiableSortedSet(new TreeSet()) for cases involving headSet, tailSet and subSet. These three operations remember the range used to create the sub set in addition to providing the elements within that range. The range is considered in a few cases such add item addition (added items must be within the range of the subset) and any subset created from a range sub set must lie within the range. Relevant to emptySortedSet is the creation of sub sets off of a ranged sub set. public static void main(String[] args) { SortedSet foo = Collections.unmodifiableSortedSet(new TreeSet()); SortedSet two = foo.headSet(Double.valueOf(2.0)); // range < 2.0 SortedSet one = two.headSet(Double.valueOf(1.0)); try { SortedSet three = two.headSet(Double.valueOf(3.0)); // IAE "toKey out of range" } catch (IllegalArgumentException expected) { expected.printStackTrace(System.err); } two = foo.tailSet(Double.valueOf(2.0)); // range >= 2.0 try { one = two.tailSet(Double.valueOf(1.0)); // IAE "fromKey out of range" } catch (IllegalArgumentException expected) { expected.printStackTrace(System.err); } SortedSet three = two.tailSet(Double.valueOf(3.0)); two = foo.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); // 2.0 <= range < 3.0 try { one = two.subSet(Double.valueOf(1.0),Double.valueOf(2.0)); // IAE "fromKey out of range" } catch (IllegalArgumentException expected) { expected.printStackTrace(System.err); } three = two.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); } This program throws three IAE exceptions. Replacing the first statement with: SortedSet foo = Collections.emptySortedSet(); would result in no IAE exceptions because they emptySortedSet() does not track ranges for sub sets derived with headSet(), tailSet() and subSet(). The range on emptySortedSet and derived sets is always fully open. Mike From jason_mehrens at hotmail.com Fri Nov 4 17:52:54 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 4 Nov 2011 12:52:54 -0500 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: References: <4EAB3049.8040409@oracle.com> <4EADF138.30604@oracle.com>, <4EB3348D.9070405@oracle.com>, Message-ID: Mike, These 'simple' classes are really hard to get right. Here is my review of the change: 1. Why not extend EmptySet? You wouldn't have to implement so many methods. 2. The comparator method is using raw types. 3. The readResolve method comment is just wrong. Create a default access static final reference named EMPTY_SORTED_SET inside of the EmptySortedSet and use that in readResolve and in Collections.emptySortedSet. 4. Only the IAE if statement is need for your range checks. NPE and CCE will occur in that if statement by default. CCE lacks a descriptive message the you get if you used Class.cast or just an implicit cast. 5. What if I want to create an empty set sorted set with supplied comparator? 6. Why not implement an EmptyNavigableSet instead since the bug was entered before 1.6? Did I make the case for a follow up review? :) Regards, Jason > Subject: Re: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) > From: mike.duigou at oracle.com > Date: Fri, 4 Nov 2011 09:29:09 -0700 > To: David.Holmes at oracle.com > CC: core-libs-dev at openjdk.java.net > > > On Nov 3 2011, at 17:40 , David Holmes wrote: > > > Mike, > > > > I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. > > I missed your question about the range on an empty set. My comments below. > > Removing EMPTY_SORTED_SET was the only other comment to my knowledge. Darryl adapted the patch and EMPTY_SORTED_SET was not part of the commit. Since the change was removal of a newly proposed field an additional review cycle wasn't thought to be necessary. Perhaps incorrectly? From Alan.Bateman at oracle.com Fri Nov 4 19:39:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Nov 2011 19:39:08 +0000 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> References: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> Message-ID: <4EB43F5C.80206@oracle.com> On 04/11/2011 12:03, Heiko Wagner wrote: > Hi Tom, thanks for your reply. I am using JNI in a different,propably never > designed to be used that way, kind of scenario. I use JNI to bring Java to a > legacy Smalltalk based product[1]. > > The Smalltalk code does directly invoke the JNI calls from its own Smalltalk > VM main thread. So the Java VM is not aware of the calling thread and has no > call stack information. Currently, I am using > ClassLoader.getSystemClassLoader(), which perfectly works for me. I have no > idea if this makes sense in gerneal, but for me a > MissingResourceBundleException in my use case, would be what I propably > would have expected, instead of a ArrayIndexOutOfBoundsException, so maybe a > additional size check on the call stack array size would make sense. > The thread must be known to the VM as otherwise you wouldn't have a JNIEnv and wouldn't be able to call the method (so I'll bet the thread is attaching via AttachCurrentThread somewhere). As to the ArrayIndexOutOfBoundsException, that does seem to be a bug as I assume that getClassContext is returning an array of one element corresponding to the caller frame (getBundle in this case). -Alan. From naoto.sato at oracle.com Fri Nov 4 21:52:06 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 04 Nov 2011 14:52:06 -0700 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <4EB43F5C.80206@oracle.com> References: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> <4EB43F5C.80206@oracle.com> Message-ID: <4EB45E86.20103@oracle.com> Yep. Please file a bug. Naoto On 11/4/11 12:39 PM, Alan Bateman wrote: > As to the ArrayIndexOutOfBoundsException, that does seem to be a bug as > I assume that getClassContext is returning an array of one element > corresponding to the caller frame (getBundle in this case). From Alan.Bateman at oracle.com Fri Nov 4 22:37:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Nov 2011 22:37:49 +0000 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EB40A21.2080105@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> Message-ID: <4EB4693D.9070705@oracle.com> On 04/11/2011 15:52, Gary Adams wrote: > : > > I'll attempt a simple fix for the KillThread case by replacing : > > Thread.sleep(100); > > with a simple loop > > do { > Thread.sleep(100); > } while (waiting); > > where the TimerTask runnable will clear the flag > with "waiting = false " once it has been launched. > I don't think this will guarantee that the timer thread will have terminated before the main thread schedules the second event. I think this test would be robust if you capture a reference to the timer thread in the first task and have the main thread wait or poll until it has a reference to the thread. Once it has a reference to the thread then it can wait for it to terminate before attempting to schedule the second task. -Alan. From lana.steuck at oracle.com Sat Nov 5 16:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20111105164707.BC4B847253@hg.openjdk.java.net> Changeset: ca977d167697 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ca977d167697 Added tag jdk8-b11 for changeset d1b7a4f6dd20 ! .hgtags Changeset: bcc739229f63 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bcc739229f63 Added tag jdk8-b12 for changeset ca977d167697 ! .hgtags From lana.steuck at oracle.com Sat Nov 5 16:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20111105164707.BF55447254@hg.openjdk.java.net> Changeset: 8e2104d565ba Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e2104d565ba Added tag jdk8-b11 for changeset 1defbc57940a ! .hgtags Changeset: 26fb81a1e9ce Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/26fb81a1e9ce Added tag jdk8-b12 for changeset 8e2104d565ba ! .hgtags From lana.steuck at oracle.com Sat Nov 5 16:47:10 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:10 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20111105164710.BC5BE47255@hg.openjdk.java.net> Changeset: e6eed2ff5d5f Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e6eed2ff5d5f Added tag jdk8-b11 for changeset a12ab897a249 ! .hgtags Changeset: adf2a6b5fde1 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/adf2a6b5fde1 Added tag jdk8-b12 for changeset e6eed2ff5d5f ! .hgtags From lana.steuck at oracle.com Sat Nov 5 16:47:07 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:07 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20111105164712.A8FEC47256@hg.openjdk.java.net> Changeset: 31d70911b712 Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/31d70911b712 Added tag jdk8-b11 for changeset 0199e4fef5cc ! .hgtags Changeset: 5b9d9b839d3d Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5b9d9b839d3d Added tag jdk8-b12 for changeset 31d70911b712 ! .hgtags From lana.steuck at oracle.com Sat Nov 5 16:47:25 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:25 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20111105164737.0309147257@hg.openjdk.java.net> Changeset: 8ff85191a7ac Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8ff85191a7ac Added tag jdk8-b11 for changeset 4bf01f1c4e34 ! .hgtags Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/11c184155128 Merge From lana.steuck at oracle.com Sat Nov 5 16:47:14 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Nov 2011 16:47:14 +0000 Subject: hg: jdk8/tl/hotspot: 34 new changesets Message-ID: <20111105164829.5A42547258@hg.openjdk.java.net> Changeset: bc257a801090 Author: jcoomes Date: 2011-10-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc257a801090 7101096: Bump the hs23 build number to 03 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 940513efe83a Author: iveresov Date: 2011-10-04 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/940513efe83a 7097679: Tiered: events with bad bci to Gotos reduced from Ifs Summary: Save bci of instruction that produced Goto and use it to call back to runtime Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: ec5ce9326985 Author: kvn Date: 2011-10-04 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec5ce9326985 6865265: JVM crashes with "missing exception handler" error Summary: Retry the call to fast_exception_handler_bci_for() after it returned with a pending exception. Don't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is for another (nested) exception. Reviewed-by: kamg, kvn Contributed-by: volker.simonis at gmail.com ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6865265/StackOverflowBug.java Changeset: eba73e0c7780 Author: bdelsart Date: 2011-10-07 13:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba73e0c7780 7096366: PPC: corruption of floating-point values with DeoptimizeALot Summary: fix for a deoptimization found on PPC, which could impact other big endian platforms Reviewed-by: roland, dholmes ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 0abefdb54d21 Author: twisti Date: 2011-10-11 02:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0abefdb54d21 7081938: JSR292: assert(magic_number_2() == MAGIC_NUMBER_2) failed Reviewed-by: never, bdelsart ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp Changeset: 5eb9169b1a14 Author: twisti Date: 2011-10-12 21:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5eb9169b1a14 7092712: JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP Reviewed-by: jrose, never ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp Changeset: a786fdc79c5f Author: never Date: 2011-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a786fdc79c5f 7100165: JSR 292: leftover printing code in methodHandleWalk.cpp Reviewed-by: kvn, twisti ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 4bac06a82bc3 Author: kvn Date: 2011-10-14 10:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bac06a82bc3 7100757: The BitSet.nextSetBit() produces incorrect result in 32bit VM on Sparc Summary: Instruction countTrailingZerosL() should use iRegIsafe dst register since it is used in long arithmetic. Reviewed-by: never, twisti ! src/cpu/sparc/vm/sparc.ad + test/compiler/7100757/Test7100757.java Changeset: 11d17c7d2ee6 Author: iveresov Date: 2011-10-16 02:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11d17c7d2ee6 Merge Changeset: 2ef3386478e6 Author: dholmes Date: 2011-10-10 21:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ef3386478e6 7096278: Update the VM name to indicate it is an embedded build Reviewed-by: kvn, never, jcoomes, bobv ! src/share/vm/runtime/vm_version.cpp Changeset: 436b4a3231bf Author: dcubed Date: 2011-10-13 09:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/436b4a3231bf 7098194: integrate macosx-port changes Summary: Integrate bsd-port/hotspot and macosx-port/hotspot changes as of 2011.09.29. Reviewed-by: kvn, dholmes, never, phh Contributed-by: Christos Zoulas , Greg Lewis , Kurt Miller , Alexander Strange , Mike Swingler , Roger Hoover , Victor Hernandez , Pratik Solanki ! .hgignore + agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/symtab.c ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! make/Makefile ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sa.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/top.make ! make/bsd/makefiles/vm.make ! make/defs.make - make/templates/bsd-header ! src/cpu/x86/vm/jni_x86.h + src/os/bsd/dtrace/generateJvmOffsets.cpp + src/os/bsd/dtrace/generateJvmOffsets.h + src/os/bsd/dtrace/generateJvmOffsetsMain.c + src/os/bsd/dtrace/hotspot.d + src/os/bsd/dtrace/hotspot_jni.d + src/os/bsd/dtrace/hs_private.d + src/os/bsd/dtrace/jhelper.d + src/os/bsd/dtrace/jvm_dtrace.c + src/os/bsd/dtrace/jvm_dtrace.h + src/os/bsd/dtrace/libjvm_db.c + src/os/bsd/dtrace/libjvm_db.h ! src/os/bsd/vm/dtraceJSDT_bsd.cpp ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.s ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/bytes_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/dtrace.hpp + src/share/vm/utilities/dtrace_usdt2_disabled.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/hashtable.cpp Changeset: 23a1c8de9d51 Author: dholmes Date: 2011-10-17 01:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23a1c8de9d51 Merge - make/templates/bsd-header ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 8187c94a9a87 Author: never Date: 2011-10-17 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8187c94a9a87 7093690: JSR292: SA-JDI AssertionFailure: Expected raw sp likely got real sp, value was Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java Changeset: e5928e7dab26 Author: never Date: 2011-10-17 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5928e7dab26 7098528: crash with java -XX:+ExtendedDTraceProbes Reviewed-by: kvn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/oops/instanceMirrorKlass.cpp Changeset: 16f9fa2bf76c Author: kvn Date: 2011-10-19 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16f9fa2bf76c 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations Summary: replace the call to memmove by a simple copy loop Reviewed-by: dholmes, kvn, never Contributed-by: axel.siebenborn at sap.com, volker.simonis at gmail.com ! src/cpu/sparc/vm/copy_sparc.hpp ! src/os_cpu/windows_x86/vm/copy_windows_x86.inline.hpp + test/runtime/7100935/TestConjointAtomicArraycopy.java + test/runtime/7100935/TestShortArraycopy.java Changeset: 1179647ee175 Author: iveresov Date: 2011-10-21 00:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1179647ee175 Merge Changeset: ec4b032a4977 Author: tonyp Date: 2011-10-13 13:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec4b032a4977 7098085: G1: partially-young GCs not initiated under certain circumstances Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 074f0252cc13 Author: tonyp Date: 2011-10-14 11:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/074f0252cc13 7088680: G1: Cleanup in the G1CollectorPolicy class Summary: Removed unused fields and methods, removed the G1CollectoryPolicy_BestRegionsFirst class and folded its functionality into the G1CollectorPolicy class. Reviewed-by: ysr, brutisso, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/universe.cpp Changeset: bf2d2b8b1726 Author: johnc Date: 2011-10-17 09:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf2d2b8b1726 7095243: Disambiguate ReferenceProcessor::_discoveredSoftRefs Summary: Add a new, separate, pointer to the base of the array of discovered reference lists and use this new pointer in places where we iterate over the entire array. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 647872693572 Author: tonyp Date: 2011-10-21 07:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/647872693572 Merge Changeset: 4d3850d9d326 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d3850d9d326 Merge - make/templates/bsd-header Changeset: 4538caeef7b6 Author: jcoomes Date: 2011-10-21 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4538caeef7b6 Added tag hs23-b03 for changeset 4d3850d9d326 ! .hgtags Changeset: 02fe430d493e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02fe430d493e Added tag jdk8-b11 for changeset 4538caeef7b6 ! .hgtags Changeset: c9d25d93ddfe Author: jcoomes Date: 2011-10-21 16:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9d25d93ddfe 7103619: Bump the hs23 build number to 04 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5e5d4821bf07 Author: brutisso Date: 2011-10-20 10:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e5d4821bf07 7097516: G1: assert(0<= from_card && from_card Changeset: e1f4b4b4b96e Author: katleman Date: 2011-10-27 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1f4b4b4b96e Added tag jdk8-b11 for changeset 7ab0d613cd1a ! .hgtags Changeset: 7746eb8c610b Author: bae Date: 2011-10-17 15:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7746eb8c610b 6997116: The case automatically failed due to java.lang.ClassCastException. Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java + test/sun/java2d/DirectX/DrawBitmaskToSurfaceTest.java Changeset: a7a001378444 Author: jgodinez Date: 2011-10-24 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7a001378444 6604109: javax.print.PrintServiceLookup.lookupPrintServices fails SOMETIMES for Cups Reviewed-by: bae, prr ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 8f9b0629d088 Author: lana Date: 2011-10-25 21:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8f9b0629d088 Merge Changeset: 7814800c64bd Author: lana Date: 2011-10-25 21:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7814800c64bd Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 09fd2067f715 Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09fd2067f715 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: d636e737c478 Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d636e737c478 Added tag jdk8-b12 for changeset 09fd2067f715 ! .hgtags Changeset: ead9dabe8c75 Author: lana Date: 2011-11-05 00:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ead9dabe8c75 Merge From Alan.Bateman at oracle.com Sun Nov 6 10:45:14 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 06 Nov 2011 10:45:14 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EB1A112.3070102@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> Message-ID: <4EB6653A.7020405@oracle.com> On 02/11/2011 19:59, David Holmes wrote: > > I'm not seeing a distinction in those two statements. Both expect to > return the property value for a given key; both assume a valid value > is a String. clearProperty throws ClassCastException if the assumption > doesn't hold; getProperty instead returns null. The distinction is "value" vs. "string value", where the latter is interpreted by Darryl's patch to be the String representation. While that avoids the CCE, it is clearly inconsistent with System.getProperty that I see is also specified to return the "string value". So I think we have to dismiss this approach. I think this leaves two options: 1. Document existing behavior, meaning @throws CCE (several of Properties methods already have this). 2. Change the method so that it is consistent with getProperty and so returns null if the property value is not a String. While option 2 is clearly a change then I think it's worth exploring to understand the impact. Properties has always had a note in its javadoc to warn users that it inherits from Hashtable and it has a note to "strongly discourage" inserting entries that have a key or value that is not a String. My guess (and this is purely a guess) is that System.clearProperty is not used very often and so the likelihood of someone abusing the system properties and using clearProperty is probably low. I see the bug on bugs.sun.com doesn't have any votes or comments which suggests that this one doesn't have an angry mob either. Darryl - since you have decided to tackle this one then I would suggest looking into this further and coming back with a recommendation. I would also suggest that as part of the patch that the javadoc for System.getProperty and Properties.getProperty be clarified so that it's clear that they return null when the properties have been compromised. -Alan. From david.holmes at oracle.com Mon Nov 7 00:19:59 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 10:19:59 +1000 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <4EB43F5C.80206@oracle.com> References: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> <4EB43F5C.80206@oracle.com> Message-ID: <4EB7242F.5030905@oracle.com> On 5/11/2011 5:39 AM, Alan Bateman wrote: > On 04/11/2011 12:03, Heiko Wagner wrote: >> Hi Tom, thanks for your reply. I am using JNI in a different,propably >> never >> designed to be used that way, kind of scenario. I use JNI to bring >> Java to a >> legacy Smalltalk based product[1]. >> >> The Smalltalk code does directly invoke the JNI calls from its own >> Smalltalk >> VM main thread. So the Java VM is not aware of the calling thread and >> has no >> call stack information. Currently, I am using >> ClassLoader.getSystemClassLoader(), which perfectly works for me. I >> have no >> idea if this makes sense in gerneal, but for me a >> MissingResourceBundleException in my use case, would be what I propably >> would have expected, instead of a ArrayIndexOutOfBoundsException, so >> maybe a >> additional size check on the call stack array size would make sense. >> > The thread must be known to the VM as otherwise you wouldn't have a > JNIEnv and wouldn't be able to call the method (so I'll bet the thread > is attaching via AttachCurrentThread somewhere). > > As to the ArrayIndexOutOfBoundsException, that does seem to be a bug as > I assume that getClassContext is returning an array of one element > corresponding to the caller frame (getBundle in this case). There are a handful of places in the JDK where this kind of stack-based check is used and the assumption is always that there is a "client" Java caller in the stack. Given this kind of code is unaware of the context in which it is called in general, what exception would you throw if you find there is no Java client caller? In the current case the specs for getBundle state that it is the equivalent of calling the classloader-taking form with the expression this.getClass().getClassLoader(). But in the current case there is no this, no current class and no current classloader - so what exception do you throw? "new RuntimeException("Expected Java caller not found")? I don't think throwing MissingResourceBundleException is the right way to go here because it hides the mis-use of this API. David > -Alan. From david.holmes at oracle.com Mon Nov 7 00:28:26 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 10:28:26 +1000 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: References: <4EAB3049.8040409@oracle.com> <4EADF138.30604@oracle.com> <4EB3348D.9070405@oracle.com> Message-ID: <4EB7262A.1000302@oracle.com> Hi Mike, On 5/11/2011 2:29 AM, Mike Duigou wrote: > > On Nov 3 2011, at 17:40 , David Holmes wrote: >> I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. > > I missed your question about the range on an empty set. My comments below. > > Removing EMPTY_SORTED_SET was the only other comment to my knowledge. Darryl adapted the patch and EMPTY_SORTED_SET was not part of the commit. Since the change was removal of a newly proposed field an additional review cycle wasn't thought to be necessary. Perhaps incorrectly? I certainly expected to see a response to the comments and to see definitive reviewer responses to the effect "I agree with this change" before it was pushed. Even if the only comment had been to drop EMPTY_SORTED_SET, I would have expected an email stating that this had been done and the amended changeset pushed. But in this case there was more to address. More inline ... >> On 31/10/2011 10:52 AM, David Holmes wrote: >>> On 29/10/2011 8:44 AM, Darryl Mocek wrote: >>>> Additional Notes to Reviewers: >>>> The sets resulting from tailSet() headSet() and subSet() normally >>>> include the range which was used to create them. Using these methods >>>> with emptySortedSet() does not currently set a range on the resulting >>>> sets. >>> >>> What is the range on an empty set? > > The results of Collections.emptySortedSet() will behave differently than Collections.unmodifiableSortedSet(new TreeSet()) for cases involving headSet, tailSet and subSet. These three operations remember the range used to create the sub set in addition to providing the elements within that range. The range is considered in a few cases such add item addition (added items must be within the range of the subset) and any subset created from a range sub set must lie within the range. Relevant to emptySortedSet is the creation of sub sets off of a ranged sub set. > > public static void main(String[] args) { > SortedSet foo = Collections.unmodifiableSortedSet(new TreeSet()); > > SortedSet two = foo.headSet(Double.valueOf(2.0)); // range< 2.0 > SortedSet one = two.headSet(Double.valueOf(1.0)); > try { > SortedSet three = two.headSet(Double.valueOf(3.0)); // IAE "toKey out of range" > } catch (IllegalArgumentException expected) { > expected.printStackTrace(System.err); > } > > two = foo.tailSet(Double.valueOf(2.0)); // range>= 2.0 > try { > one = two.tailSet(Double.valueOf(1.0)); // IAE "fromKey out of range" > } catch (IllegalArgumentException expected) { > expected.printStackTrace(System.err); > } > SortedSet three = two.tailSet(Double.valueOf(3.0)); > > two = foo.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); // 2.0<= range< 3.0 > try { > one = two.subSet(Double.valueOf(1.0),Double.valueOf(2.0)); // IAE "fromKey out of range" > } catch (IllegalArgumentException expected) { > expected.printStackTrace(System.err); > } > three = two.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); > } > > This program throws three IAE exceptions. Replacing the first statement with: > > SortedSet foo = Collections.emptySortedSet(); > > would result in no IAE exceptions because they emptySortedSet() does not track ranges for sub sets derived with headSet(), tailSet() and subSet(). The range on emptySortedSet and derived sets is always fully open. Naively perhaps I would have expected the range on an empty set to be fully closed, rather than fully open. That aside it is unclear what this means from an API specification perspective. Is this difference in behaviour an error ie does it violate the spec? Is it simply inconsistent with other collections, but allowed by the spec? Could we in fact "fix" it? If we can why didn't we? Cheers, David > Mike From david.holmes at oracle.com Mon Nov 7 01:05:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 11:05:23 +1000 Subject: Timing bugs In-Reply-To: <4EB3EA75.2050006@oracle.com> References: <4EB3EA75.2050006@oracle.com> Message-ID: <4EB72ED3.40702@oracle.com> Hi Gary, On 4/11/2011 11:36 PM, Gary Adams wrote: > I've started to look at timing related bugs that have been open > for a while, but have not had sufficient priority to make it to the > top of the list of bugs to be fixed. Thought I'd start with some > low hanging fruit with simple bug fixes. Sometimes apparently low-hanging fruit is attached to the tree with steel wire ;-) (and sometimes barbed wire at that) > 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the > execution time of System.out.printf > > This seems like a simply problem to avoid two calls to get the current time > and to eliminated the time to process the print statement > from the evaluation of the test elapsed time. > > Replacing this sequence ; > > System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); > check(System.currentTimeMillis() - start < 500); > > with > > elapsed = System.currentTimeMillis() - start; > System.out.printf("elapsed=%d%n", elapsed); > check(elapsed < 500); This seems reasonable on the face of it. But a couple of other observations regarding the test code: First the 500 is somewhat arbitrary - the test is preparing three timertasks with initial expiry times in the past and expecting them to all execute "immediately" (one multiple times). This immediacy is translated into "completes within 500ms". These type of timing constants should be eradicated if possible, or preferably made configurable if not. It is a difficult problem to address if you want to try and detect something taking an unexpectedly long time, but have no idea what your execution environment will be. Second, the current code won't detect a true failure that results in a hang - the testcase will hang and presumably get timed-out by the test harness. It might be better to apply a timeout to the await() calls instead and fail only if they do timeout. Third, in this case it would also be prudent to (re-)read the start time after the setup has been done ie after creating the countDownLatches. If this is run in samevm mode or agentvm mode those constructions may trigger a full GC and the ensuing delay could cause the test to again fail. That all said, I'd see combining your suggested fix with moving the point at which start is measured as definite improvements in the test. > I plan to test the fix on a 300MHz linux/arm device. > I'll provide a proper webrev as soon as I have author rights > confirmed. I'm looking for reviewer and a committer, > once I get the fix tested locally. I presume by "committer" you mean somebody to actually do the push for you - I think we generally refer to that as a "sponsor" (even though not part of OpenJDK terminology). In any case that should be someone from TL group and I'll let them respond further on that and provide any additional review comments. I'm happy to act as another Reviewer. Cheers, David > Thanks > Gary Adams > From forax at univ-mlv.fr Mon Nov 7 01:08:17 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Nov 2011 02:08:17 +0100 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EB7262A.1000302@oracle.com> References: <4EAB3049.8040409@oracle.com> <4EADF138.30604@oracle.com> <4EB3348D.9070405@oracle.com> <4EB7262A.1000302@oracle.com> Message-ID: <4EB72F81.8080104@univ-mlv.fr> On 11/07/2011 01:28 AM, David Holmes wrote: > Hi Mike, > > On 5/11/2011 2:29 AM, Mike Duigou wrote: >> >> On Nov 3 2011, at 17:40 , David Holmes wrote: >>> I see that you have pushed a version of this change and that I was >>> listed as a reviewer. However I never saw an updated webrev and >>> there was no response to my query below. In fact I never saw any >>> response to any of the reviewers comments on this. >> >> I missed your question about the range on an empty set. My comments >> below. >> >> Removing EMPTY_SORTED_SET was the only other comment to my knowledge. >> Darryl adapted the patch and EMPTY_SORTED_SET was not part of the >> commit. Since the change was removal of a newly proposed field an >> additional review cycle wasn't thought to be necessary. Perhaps >> incorrectly? > > I certainly expected to see a response to the comments and to see > definitive reviewer responses to the effect "I agree with this change" > before it was pushed. Even if the only comment had been to drop > EMPTY_SORTED_SET, I would have expected an email stating that this had > been done and the amended changeset pushed. But in this case there was > more to address. > > More inline ... > > >>> On 31/10/2011 10:52 AM, David Holmes wrote: >>>> On 29/10/2011 8:44 AM, Darryl Mocek wrote: >>>>> Additional Notes to Reviewers: >>>>> The sets resulting from tailSet() headSet() and subSet() normally >>>>> include the range which was used to create them. Using these methods >>>>> with emptySortedSet() does not currently set a range on the resulting >>>>> sets. >>>> >>>> What is the range on an empty set? >> >> The results of Collections.emptySortedSet() will behave differently >> than Collections.unmodifiableSortedSet(new TreeSet()) for cases >> involving headSet, tailSet and subSet. These three operations >> remember the range used to create the sub set in addition to >> providing the elements within that range. The range is considered in >> a few cases such add item addition (added items must be within the >> range of the subset) and any subset created from a range sub set must >> lie within the range. Relevant to emptySortedSet is the creation of >> sub sets off of a ranged sub set. >> >> public static void main(String[] args) { >> SortedSet foo = Collections.unmodifiableSortedSet(new >> TreeSet()); >> >> SortedSet two = foo.headSet(Double.valueOf(2.0)); // >> range< 2.0 >> SortedSet one = two.headSet(Double.valueOf(1.0)); >> try { >> SortedSet three = two.headSet(Double.valueOf(3.0)); >> // IAE "toKey out of range" >> } catch (IllegalArgumentException expected) { >> expected.printStackTrace(System.err); >> } >> >> two = foo.tailSet(Double.valueOf(2.0)); // range>= 2.0 >> try { >> one = two.tailSet(Double.valueOf(1.0)); // IAE "fromKey out >> of range" >> } catch (IllegalArgumentException expected) { >> expected.printStackTrace(System.err); >> } >> SortedSet three = two.tailSet(Double.valueOf(3.0)); >> >> two = foo.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); // >> 2.0<= range< 3.0 >> try { >> one = two.subSet(Double.valueOf(1.0),Double.valueOf(2.0)); >> // IAE "fromKey out of range" >> } catch (IllegalArgumentException expected) { >> expected.printStackTrace(System.err); >> } >> three = two.subSet(Double.valueOf(2.0),Double.valueOf(3.0)); >> } >> >> This program throws three IAE exceptions. Replacing the first >> statement with: >> >> SortedSet foo = Collections.emptySortedSet(); >> >> would result in no IAE exceptions because they emptySortedSet() does >> not track ranges for sub sets derived with headSet(), tailSet() and >> subSet(). The range on emptySortedSet and derived sets is always >> fully open. > > Naively perhaps I would have expected the range on an empty set to be > fully closed, rather than fully open. The spec clearly says that headSet/tailSet creates subsets that should check one of their bounds regardless if the master set is empty or not. > > That aside it is unclear what this means from an API specification > perspective. Is this difference in behaviour an error ie does it > violate the spec? Yes. > Is it simply inconsistent with other collections, but allowed by the > spec? No > Could we in fact "fix" it? Yes > If we can why didn't we? perhaps because it's weird to have a view of a stateless collection which is not stateless. The other solution is to relax the spec to say that the returned set may be not a restricted and make the IAE optional. > > Cheers, > David > >> Mike R?mi From david.holmes at oracle.com Mon Nov 7 01:46:25 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 11:46:25 +1000 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EB4693D.9070705@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> <4EB4693D.9070705@oracle.com> Message-ID: <4EB73871.2090408@oracle.com> On 5/11/2011 8:37 AM, Alan Bateman wrote: > On 04/11/2011 15:52, Gary Adams wrote: >> : >> >> I'll attempt a simple fix for the KillThread case by replacing : >> >> Thread.sleep(100); >> >> with a simple loop >> >> do { >> Thread.sleep(100); >> } while (waiting); >> >> where the TimerTask runnable will clear the flag >> with "waiting = false " once it has been launched. >> > I don't think this will guarantee that the timer thread will have > terminated before the main thread schedules the second event. I think > this test would be robust if you capture a reference to the timer thread > in the first task and have the main thread wait or poll until it has a > reference to the thread. Once it has a reference to the thread then it > can wait for it to terminate before attempting to schedule the second task. Agreed. As soon as waiting is set we can switch back to the main thread and proceed to the next phase of the test - but the timer thread is still alive at that point. If the issue is checking for thread termination then we must track that directly. David ----- > -Alan. From david.holmes at oracle.com Mon Nov 7 01:49:44 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 11:49:44 +1000 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EB40A21.2080105@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> Message-ID: <4EB73938.6070703@oracle.com> On 5/11/2011 1:52 AM, Gary Adams wrote: > I'm taking a look at some older timing based bugs that may cause problems > on slower machines > > 6818464: TEST_BUG: Timeout values in several java/util tests are > insufficient > > I'd like to split this bug into two, based on the example problems that are > mentioned in the bug report. > > The first example in > java/util/Timer/KillThread.java > In the second example the test instructions present a timeout > to be enforced by the outer test harness. e.g. > @run main/timeout=20 StoreDeadLock > > This type of test limit is easily addressed on slower machines > using the test harness timefactor to scale the acceptable > test run time. Not sure that is the case in general. Use of timefactor was suggested when running in Xcomp mode because the top-level test configuration knows it is running the tests in Xcomp mode. But in general the test harness does not know when any given test is running on a slower machine, or a not-so-slow but heavily loaded machine. David ----- > I'll attempt a simple fix for the KillThread case by replacing : > > Thread.sleep(100); > > with a simple loop > > do { > Thread.sleep(100); > } while (waiting); > > where the TimerTask runnable will clear the flag > with "waiting = false " once it has been launched. > > > From Alan.Bateman at oracle.com Mon Nov 7 08:45:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Nov 2011 08:45:06 +0000 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <4EB7242F.5030905@oracle.com> References: <50110C84EA8B42BC832A6EFDEFEE4E8A@HEIKOXP> <4EB43F5C.80206@oracle.com> <4EB7242F.5030905@oracle.com> Message-ID: <4EB79A92.2060203@oracle.com> On 07/11/2011 00:19, David Holmes wrote: > > There are a handful of places in the JDK where this kind of > stack-based check is used and the assumption is always that there is a > "client" Java caller in the stack. Given this kind of code is unaware > of the context in which it is called in general, what exception would > you throw if you find there is no Java client caller? In the current > case the specs for getBundle state that it is the equivalent of > calling the classloader-taking form with the expression > this.getClass().getClassLoader(). But in the current case there is no > this, no current class and no current classloader - so what exception > do you throw? "new RuntimeException("Expected Java caller not found")? > > I don't think throwing MissingResourceBundleException is the right way > to go here because it hides the mis-use of this API. For this specific case it probably has to be treated as if the caller's loader is the boot class loader. In that case, MissingResourceException may be thrown (I can't tell from the original mail if the resource bundle is found when the loader is specified as null, I assume not). -Alan. From heiko.wagner at apis.de Mon Nov 7 08:47:47 2011 From: heiko.wagner at apis.de (Heiko Wagner) Date: Mon, 7 Nov 2011 09:47:47 +0100 Subject: ArrayIndexOutOfBoundsException in ResourceBundle.getBundle(String)in JDK 6&7 In-Reply-To: <4EB7242F.5030905@oracle.com> Message-ID: <49D2E54406A947D48587107D7E75FD10@HEIKOXP> On 5/11/2011 5:39 AM, Alan Bateman wrote: > On 04/11/2011 12:03, Heiko Wagner wrote: >> Hi Tom, thanks for your reply. I am using JNI in a different,propably >> never >> designed to be used that way, kind of scenario. I use JNI to bring >> Java to a >> legacy Smalltalk based product[1]. >> >> The Smalltalk code does directly invoke the JNI calls from its own >> Smalltalk >> VM main thread. So the Java VM is not aware of the calling thread and >> has no >> call stack information. Currently, I am using >> ClassLoader.getSystemClassLoader(), which perfectly works for me. I >> have no >> idea if this makes sense in gerneal, but for me a >> MissingResourceBundleException in my use case, would be what I propably >> would have expected, instead of a ArrayIndexOutOfBoundsException, so >> maybe a >> additional size check on the call stack array size would make sense. >> > The thread must be known to the VM as otherwise you wouldn't have a > JNIEnv and wouldn't be able to call the method (so I'll bet the thread > is attaching via AttachCurrentThread somewhere). > > As to the ArrayIndexOutOfBoundsException, that does seem to be a bug as > I assume that getClassContext is returning an array of one element > corresponding to the caller frame (getBundle in this case). >There are a handful of places in the JDK where this kind of stack-based >check is used and the assumption is always that there is a "client" Java >caller in the stack. Given this kind of code is unaware of the context >in which it is called in general, what exception would you throw if you >find there is no Java client caller? In the current case the specs for >getBundle state that it is the equivalent of calling the >classloader-taking form with the expression >this.getClass().getClassLoader(). But in the current case there is no >this, no current class and no current classloader - so what exception do >you throw? "new RuntimeException("Expected Java caller not found")? >I don't think throwing MissingResourceBundleException is the right way >to go here because it hides the mis-use of this API. >David Hi, David. I agree that it is a mis-use use of the API. I would be perfectly happy, if the error message would more obviously state this fact. In my opinion the ArrayIndexOutOfBoundsException does not properly reflect this. If you take Class.forName(String) as an example, which also tries to determine the classloader of the caller, when being used this way, it throws a ClassNotFoundException, also hiding the API mis-use. So the patter here looks to me like: No Java caller -> No classloader -> No class -> ClassNotFoundException So my initial idea followed that bevaviour: No Java caller -> No classloader -> No ResourceBundle -> MissingResourceBundleException Don't get me wrong I don't want to state, that the JRE is something wrong. I just wanted to state that it would be nice, if the JRE could give developers, that are, just like me, not aware of the fact that some methods just can't be invoked directly from JNI, a better hint to that fact. Regards, Heiko From Alan.Bateman at oracle.com Mon Nov 7 08:51:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 07 Nov 2011 08:51:45 +0000 Subject: Timing bugs In-Reply-To: <4EB72ED3.40702@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB72ED3.40702@oracle.com> Message-ID: <4EB79C21.1050509@oracle.com> On 07/11/2011 01:05, David Holmes wrote: > > Sometimes apparently low-hanging fruit is attached to the tree with > steel wire ;-) (and sometimes barbed wire at that) In the case of some of our tests then it's actually fuse wire, with a nice little surprise when you yank at it :-) From Ulf.Zibis at gmx.de Mon Nov 7 11:40:55 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 07 Nov 2011 12:40:55 +0100 Subject: Who is on Dedoxx? Message-ID: <4EB7C3C7.6070001@gmx.de> Hi all, I want to know, if there are any members of the list participating on the Devoxx Conference next week. Thanks for your response, -Ulf From sean.coffey at oracle.com Mon Nov 7 11:42:12 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 07 Nov 2011 11:42:12 +0000 Subject: code review request : 7091388:Regular unexplained npe's from corba libs after system has been running for days Message-ID: <4EB7C414.5040403@oracle.com> currently not live on bugs.sun.com but hope to get it up there shortly : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7091388 I'm porting fix for 7091388 forward to JDK8 (and then 7u) This is a fix in the CDRInputStream_1_0.close()/ CDROutputStream_1_0.close() methods where shared buffers may be incorrectly closed out if the System.identityHashCode method incorrectly identify two buffers as being equal. Fix is to use the "==" operator to test if buffers are equal instead of System.identityHashCode http://cr.openjdk.java.net/~coffeys/webrev.7091388.jdk8/ Regards, Sean. From gary.adams at oracle.com Mon Nov 7 12:28:30 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 07 Nov 2011 07:28:30 -0500 Subject: Timing bugs In-Reply-To: <4EB72ED3.40702@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB72ED3.40702@oracle.com> Message-ID: <4EB7CEEE.1020307@oracle.com> On 11/ 6/11 08:05 PM, David Holmes wrote: > Hi Gary, > > On 4/11/2011 11:36 PM, Gary Adams wrote: >> I've started to look at timing related bugs that have been open >> for a while, but have not had sufficient priority to make it to the >> top of the list of bugs to be fixed. Thought I'd start with some >> low hanging fruit with simple bug fixes. > > Sometimes apparently low-hanging fruit is attached to the tree with steel wire > ;-) (and sometimes barbed wire at that) Had a feeling when I pulled on the fruit the trap door would open in the floor ... > >> 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the >> execution time of System.out.printf >> >> This seems like a simply problem to avoid two calls to get the current time >> and to eliminated the time to process the print statement >> from the evaluation of the test elapsed time. >> >> Replacing this sequence ; >> >> System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); >> check(System.currentTimeMillis() - start < 500); >> >> with >> >> elapsed = System.currentTimeMillis() - start; >> System.out.printf("elapsed=%d%n", elapsed); >> check(elapsed < 500); > > This seems reasonable on the face of it. But a couple of other observations > regarding the test code: > > First the 500 is somewhat arbitrary - the test is preparing three timertasks > with initial expiry times in the past and expecting them to all execute > "immediately" (one multiple times). This immediacy is translated into > "completes within 500ms". These type of timing constants should be eradicated > if possible, or preferably made configurable if not. It is a difficult problem > to address if you want to try and detect something taking an unexpectedly long > time, but have no idea what your execution environment will be. I think I'm signing up for making this one test reliable and not taking on all of the bad timeout assumptions. The 500 millisecond constraint seems reasonable in this case for the work expected to be completed. > > Second, the current code won't detect a true failure that results in a hang - > the testcase will hang and presumably get timed-out by the test harness. It > might be better to apply a timeout to the await() calls instead and fail only > if they do timeout. I thought the hung test was the responsibility of the test harness. It makes for simpler individual tests if that responsibility is delegated to the harness. > > Third, in this case it would also be prudent to (re-)read the start time after > the setup has been done ie after creating the countDownLatches. If this is run > in samevm mode or agentvm mode those constructions may trigger a full GC and > the ensuing delay could cause the test to again fail. Sounds reasonable I'll add that change to the fix. > > That all said, I'd see combining your suggested fix with moving the point at > which start is measured as definite improvements in the test. Agreed. > >> I plan to test the fix on a 300MHz linux/arm device. >> I'll provide a proper webrev as soon as I have author rights >> confirmed. I'm looking for reviewer and a committer, >> once I get the fix tested locally. > > I presume by "committer" you mean somebody to actually do the push for you - I > think we generally refer to that as a "sponsor" (even though not part of > OpenJDK terminology). In any case that should be someone from TL group and > I'll let them respond further on that and provide any additional review comments. > > I'm happy to act as another Reviewer. Thanks. > > Cheers, > David > >> Thanks >> Gary Adams >> From gary.adams at oracle.com Mon Nov 7 16:03:58 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 07 Nov 2011 11:03:58 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB3EA75.2050006@oracle.com> References: <4EB3EA75.2050006@oracle.com> Message-ID: <4EB8016E.2050100@oracle.com> Here's another test with race conditions built into the test that can be easily avoided CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently There are at least two race conditions in the test as currently written. The test uses sleeps as a way to yield time to other threads to complete their tasks, but this may not be sufficient on slower machines. The first race condition is in the starting of the test threads. To ensure both threads are started, the run check for the first thread should also check that the second thread is not null. The second race condition in the main thread presumes that the group stop has been issued within 3000 milliseconds. A simple loop on the delay can be gated by a flag set after the group stop has been issued. diff --git a/test/java/lang/ThreadGroup/Stop.java b/test/java/lang/ThreadGroup/Stop.java --- a/test/java/lang/ThreadGroup/Stop.java +++ b/test/java/lang/ThreadGroup/Stop.java @@ -32,6 +32,7 @@ private static Thread first=null; private static Thread second=null; private static ThreadGroup group = new ThreadGroup(""); + private static boolean groupStopped =false ; Stop() { Thread thread = new Thread(group, this); @@ -47,8 +48,11 @@ while (true) { try { Thread.sleep(1000); // Give other thread a chance to start - if (Thread.currentThread() == first) + if ((Thread.currentThread() == first) + && (second != null)) { + groupStopped = true; group.stop(); + } } catch(InterruptedException e){ } } @@ -57,7 +61,10 @@ public static void main(String[] args) throws Exception { for (int i=0; i<2; i++) new Stop(); + do { Thread.sleep(3000); + } while (!groupStopped) ; + boolean failed = second.isAlive(); first.stop(); second.stop(); if (failed) From forax at univ-mlv.fr Mon Nov 7 17:43:08 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Nov 2011 18:43:08 +0100 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB8016E.2050100@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> Message-ID: <4EB818AC.30807@univ-mlv.fr> On 11/07/2011 05:03 PM, Gary Adams wrote: > > > Here's another test with race conditions built into the test > that can be easily avoided > > CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails > intermittently > > There are at least two race conditions in the test as currently written. > The test uses sleeps as a way to yield time to other threads to > complete their > tasks, but this may not be sufficient on slower machines. > > The first race condition is in the starting of the test threads. > To ensure both threads are started, the run check for the first thread > should > also check that the second thread is not null. > > The second race condition in the main thread presumes that > the group stop has been issued within 3000 milliseconds. > A simple loop on the delay can be gated by a flag set after the group > stop has been issued. Hi Gary, groupStopped should be at least volatile or ... it's perhaps better to use wait() instead of sleep(), to use notifyAll() when groupStopped is equals to true and to use a lock object to synchronize the wait and the notifyAll block. something like private static Thread first=null; private static Thread second=null; private static ThreadGroup group = new ThreadGroup(""); + private static boolean groupStopped =false ; + private static final Object lock = new Object(); Stop() { Thread thread = new Thread(group, this); @@ -47,8 +48,11 @@ while (true) { try { Thread.sleep(1000); // Give other thread a chance to start - if (Thread.currentThread() == first) + if ((Thread.currentThread() == first) + && (second != null)) { + synchronized(lock) { + groupStopped = true; group.stop(); + lock.notifyAll(); + } + } } catch(InterruptedException e){ } } @@ -57,7 +61,10 @@ public static void main(String[] args) throws Exception { for (int i=0; i<2; i++) new Stop(); + synchronized(lock) { + while(!groupStopped) { lock.wait(); + } + } + boolean failed = second.isAlive(); first.stop(); second.stop(); if (failed) R?mi > > diff --git a/test/java/lang/ThreadGroup/Stop.java > b/test/java/lang/ThreadGroup/Stop.java > --- a/test/java/lang/ThreadGroup/Stop.java > +++ b/test/java/lang/ThreadGroup/Stop.java > @@ -32,6 +32,7 @@ > private static Thread first=null; > private static Thread second=null; > private static ThreadGroup group = new ThreadGroup(""); > + private static boolean groupStopped =false ; > > Stop() { > Thread thread = new Thread(group, this); > @@ -47,8 +48,11 @@ > while (true) { > try { > Thread.sleep(1000); // Give other thread a chance to > start > - if (Thread.currentThread() == first) > + if ((Thread.currentThread() == first) > + && (second != null)) { > + groupStopped = true; > group.stop(); > + } > } catch(InterruptedException e){ > } > } > @@ -57,7 +61,10 @@ > public static void main(String[] args) throws Exception { > for (int i=0; i<2; i++) > new Stop(); > + do { > Thread.sleep(3000); > + } while (!groupStopped) ; > + > boolean failed = second.isAlive(); > first.stop(); second.stop(); > if (failed) > > > From chris.hegarty at oracle.com Mon Nov 7 18:28:33 2011 From: chris.hegarty at oracle.com (chris hegarty) Date: Mon, 07 Nov 2011 18:28:33 +0000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB8016E.2050100@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> Message-ID: <4EB82351.9020001@oracle.com> Hi Gary, Thanks for taking this bug. In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to coordinate between threads. So, you could completely remove the sleep(1000) from the run method and use a Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will reach a particular point before invoking stop on the group. That way, either thread can invoke stop and set the flag to prevent the other thread from invoking stop too ( if it were to get there! ). I agree with R?mi's comments about wait/notify. My comments (above) should work with well with his suggestion. Then no more nasty sleeps! Thanks, -Chris. On 07/11/2011 16:03, Gary Adams wrote: > > > Here's another test with race conditions built into the test > that can be easily avoided > > CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails > intermittently > > There are at least two race conditions in the test as currently written. > The test uses sleeps as a way to yield time to other threads to complete > their > tasks, but this may not be sufficient on slower machines. > > The first race condition is in the starting of the test threads. > To ensure both threads are started, the run check for the first thread > should > also check that the second thread is not null. > > The second race condition in the main thread presumes that > the group stop has been issued within 3000 milliseconds. > A simple loop on the delay can be gated by a flag set after the group > stop has been issued. > > diff --git a/test/java/lang/ThreadGroup/Stop.java > b/test/java/lang/ThreadGroup/Stop.java > --- a/test/java/lang/ThreadGroup/Stop.java > +++ b/test/java/lang/ThreadGroup/Stop.java > @@ -32,6 +32,7 @@ > private static Thread first=null; > private static Thread second=null; > private static ThreadGroup group = new ThreadGroup(""); > + private static boolean groupStopped =false ; > > Stop() { > Thread thread = new Thread(group, this); > @@ -47,8 +48,11 @@ > while (true) { > try { > Thread.sleep(1000); // Give other thread a chance to start > - if (Thread.currentThread() == first) > + if ((Thread.currentThread() == first) > + && (second != null)) { > + groupStopped = true; > group.stop(); > + } > } catch(InterruptedException e){ > } > } > @@ -57,7 +61,10 @@ > public static void main(String[] args) throws Exception { > for (int i=0; i<2; i++) > new Stop(); > + do { > Thread.sleep(3000); > + } while (!groupStopped) ; > + > boolean failed = second.isAlive(); > first.stop(); second.stop(); > if (failed) > > > From gary.adams at oracle.com Mon Nov 7 18:37:25 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 07 Nov 2011 13:37:25 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB82351.9020001@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> Message-ID: <4EB82565.8040803@oracle.com> On 11/ 7/11 01:28 PM, chris hegarty wrote: > Hi Gary, > > Thanks for taking this bug. Alan was the one to suggest this as an easy starter bug. > > In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to > coordinate between threads. So, you could completely remove the sleep(1000) > from the run method and use a Phaser.arriveAndAwaitAdvance(). This will > guarantee both threads will reach a particular point before invoking stop on > the group. That way, either thread can invoke stop and set the flag to prevent > the other thread from invoking stop too ( if it were to get there! ). Thanks I'll take a look at using Phaser as a replacement mechanism. > > I agree with R?mi's comments about wait/notify. My comments (above) should > work with well with his suggestion. Then no more nasty sleeps! One tweak to the notifyAll solution, it needs to be invoked before the group stop is issued. > > Thanks, > -Chris. > > On 07/11/2011 16:03, Gary Adams wrote: >> >> >> Here's another test with race conditions built into the test >> that can be easily avoided >> >> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >> intermittently >> >> There are at least two race conditions in the test as currently written. >> The test uses sleeps as a way to yield time to other threads to complete >> their >> tasks, but this may not be sufficient on slower machines. >> >> The first race condition is in the starting of the test threads. >> To ensure both threads are started, the run check for the first thread >> should >> also check that the second thread is not null. >> >> The second race condition in the main thread presumes that >> the group stop has been issued within 3000 milliseconds. >> A simple loop on the delay can be gated by a flag set after the group >> stop has been issued. >> >> diff --git a/test/java/lang/ThreadGroup/Stop.java >> b/test/java/lang/ThreadGroup/Stop.java >> --- a/test/java/lang/ThreadGroup/Stop.java >> +++ b/test/java/lang/ThreadGroup/Stop.java >> @@ -32,6 +32,7 @@ >> private static Thread first=null; >> private static Thread second=null; >> private static ThreadGroup group = new ThreadGroup(""); >> + private static boolean groupStopped =false ; >> >> Stop() { >> Thread thread = new Thread(group, this); >> @@ -47,8 +48,11 @@ >> while (true) { >> try { >> Thread.sleep(1000); // Give other thread a chance to start >> - if (Thread.currentThread() == first) >> + if ((Thread.currentThread() == first) >> + && (second != null)) { >> + groupStopped = true; >> group.stop(); >> + } >> } catch(InterruptedException e){ >> } >> } >> @@ -57,7 +61,10 @@ >> public static void main(String[] args) throws Exception { >> for (int i=0; i<2; i++) >> new Stop(); >> + do { >> Thread.sleep(3000); >> + } while (!groupStopped) ; >> + >> boolean failed = second.isAlive(); >> first.stop(); second.stop(); >> if (failed) >> >> >> From patrick at reini.net Mon Nov 7 19:20:25 2011 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 07 Nov 2011 20:20:25 +0100 Subject: Who is on Dedoxx? In-Reply-To: <4EB7C3C7.6070001@gmx.de> References: <4EB7C3C7.6070001@gmx.de> Message-ID: <4EB82F79.6090407@reini.net> Hi Ulf, I will be there.. Cheers Patrick "Reini" Reinhart Am 7.11.2011 12:40, schrieb Ulf Zibis: > Hi all, > > I want to know, if there are any members of the list participating on > the Devoxx Conference next week. > > Thanks for your response, > > -Ulf > From dalibor.topic at oracle.com Mon Nov 7 19:28:16 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 07 Nov 2011 20:28:16 +0100 Subject: Who is on Dedoxx? In-Reply-To: <4EB82F79.6090407@reini.net> References: <4EB7C3C7.6070001@gmx.de> <4EB82F79.6090407@reini.net> Message-ID: <4EB83150.1090408@oracle.com> On 11/7/11 8:20 PM, Patrick Reinhart wrote: > Hi Ulf, > > I will be there.. There will be an OpenJDK Community BOF [0] at Devoxx on Tuesday, so if you're there, do stop by! cheers, dalibor topic [0] http://devoxx.com/display/DV11/The+OpenJDK+Community+BOF -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From xueming.shen at oracle.com Mon Nov 7 20:30:40 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Nov 2011 12:30:40 -0800 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4EAAD4FD.3060302@oracle.com> References: <4E83730A.8060106@oracle.com> <4EAAD4FD.3060302@oracle.com> Message-ID: <4EB83FF0.40607@oracle.com> Thanks Alan, The webrev has been updated accordingly to address your comments (the commented out isMalformed2 has been removed, copyright updated, bugid added...) And thanks for Ulf for the detailed review. -Sherman On 10/28/2011 09:14 AM, Alan Bateman wrote: > On 28/09/2011 20:18, Xueming Shen wrote: >> Hi, >> >> [I combined the proposed charge for #7082884, in which no one appears >> to be >> interested:-) into this one] >> : >> >> http://cr.openjdk.java.net/~sherman/7096080/webrev/ >> > I don't know if you are still looking for a reviewer for this (seems > like Ulf has gone through this in detail, thanks Ulf). > > Overall it looks fine to me. Minor comment is that in UTF_8.java then > maybe isMalformed2 should be removed completely, maybe move some of > the comment in the decode methods. Another minor nits is that the date > on CESU_8.java is 2000-2010 where I assume it should be 2011. In > Errors.java then it might be better to just remove L196 as it might > confuse future maintainers. I would also suggest adding the bugID to > the list of bugs in the tests too as someone these references are useful. > > -Alan. From brian.goetz at oracle.com Mon Nov 7 20:50:08 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 7 Nov 2011 15:50:08 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB82351.9020001@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> Message-ID: <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> Wait/notify may be better than sleeping, but semaphore/latch/barrier are much better than wait/notify. Much. Sent from my iPhone On Nov 7, 2011, at 1:28 PM, chris hegarty wrote: > Hi Gary, > > Thanks for taking this bug. > > In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to coordinate between threads. So, you could completely remove the sleep(1000) from the run method and use a Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will reach a particular point before invoking stop on the group. That way, either thread can invoke stop and set the flag to prevent the other thread from invoking stop too ( if it were to get there! ). > > I agree with R?mi's comments about wait/notify. My comments (above) should work with well with his suggestion. Then no more nasty sleeps! > > Thanks, > -Chris. > > On 07/11/2011 16:03, Gary Adams wrote: >> >> >> Here's another test with race conditions built into the test >> that can be easily avoided >> >> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >> intermittently >> >> There are at least two race conditions in the test as currently written. >> The test uses sleeps as a way to yield time to other threads to complete >> their >> tasks, but this may not be sufficient on slower machines. >> >> The first race condition is in the starting of the test threads. >> To ensure both threads are started, the run check for the first thread >> should >> also check that the second thread is not null. >> >> The second race condition in the main thread presumes that >> the group stop has been issued within 3000 milliseconds. >> A simple loop on the delay can be gated by a flag set after the group >> stop has been issued. >> >> diff --git a/test/java/lang/ThreadGroup/Stop.java >> b/test/java/lang/ThreadGroup/Stop.java >> --- a/test/java/lang/ThreadGroup/Stop.java >> +++ b/test/java/lang/ThreadGroup/Stop.java >> @@ -32,6 +32,7 @@ >> private static Thread first=null; >> private static Thread second=null; >> private static ThreadGroup group = new ThreadGroup(""); >> + private static boolean groupStopped =false ; >> >> Stop() { >> Thread thread = new Thread(group, this); >> @@ -47,8 +48,11 @@ >> while (true) { >> try { >> Thread.sleep(1000); // Give other thread a chance to start >> - if (Thread.currentThread() == first) >> + if ((Thread.currentThread() == first) >> + && (second != null)) { >> + groupStopped = true; >> group.stop(); >> + } >> } catch(InterruptedException e){ >> } >> } >> @@ -57,7 +61,10 @@ >> public static void main(String[] args) throws Exception { >> for (int i=0; i<2; i++) >> new Stop(); >> + do { >> Thread.sleep(3000); >> + } while (!groupStopped) ; >> + >> boolean failed = second.isAlive(); >> first.stop(); second.stop(); >> if (failed) >> >> >> From Ulf.Zibis at gmx.de Mon Nov 7 20:57:52 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 07 Nov 2011 21:57:52 +0100 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4EB83FF0.40607@oracle.com> References: <4E83730A.8060106@oracle.com> <4EAAD4FD.3060302@oracle.com> <4EB83FF0.40607@oracle.com> Message-ID: <4EB84650.1060905@gmx.de> Hi Sherman, 2 nits again: protected static final class Encoder extends CharsetEncoder - If final, protected doesn't make sense, as it can't be subclassed. (ideally this should be a compiler error) - Where is it used? Otherwise it could be private. -Ulf Am 07.11.2011 21:30, schrieb Xueming Shen: > Thanks Alan, > > The webrev has been updated accordingly to address your comments (the > commented out isMalformed2 has been removed, copyright updated, bugid > added...) > > And thanks for Ulf for the detailed review. > > -Sherman > > On 10/28/2011 09:14 AM, Alan Bateman wrote: >> On 28/09/2011 20:18, Xueming Shen wrote: >>> Hi, >>> >>> [I combined the proposed charge for #7082884, in which no one appears to be >>> interested:-) into this one] >>> : >>> >>> http://cr.openjdk.java.net/~sherman/7096080/webrev/ >>> >> I don't know if you are still looking for a reviewer for this (seems like Ulf has gone through >> this in detail, thanks Ulf). >> >> Overall it looks fine to me. Minor comment is that in UTF_8.java then maybe isMalformed2 should >> be removed completely, maybe move some of the comment in the decode methods. Another minor nits >> is that the date on CESU_8.java is 2000-2010 where I assume it should be 2011. In Errors.java >> then it might be better to just remove L196 as it might confuse future maintainers. I would also >> suggest adding the bugID to the list of bugs in the tests too as someone these references are >> useful. >> >> -Alan. > > From xueming.shen at oracle.com Mon Nov 7 21:28:53 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 07 Nov 2011 13:28:53 -0800 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4EB84650.1060905@gmx.de> References: <4E83730A.8060106@oracle.com> <4EAAD4FD.3060302@oracle.com> <4EB83FF0.40607@oracle.com> <4EB84650.1060905@gmx.de> Message-ID: <4EB84D95.7050502@oracle.com> Hi Ulf, Good catch. It was the leftover of my first drift, in which CESU.de/encoder is the subclass of the UTF8 de/encoder. webrev has been updated accordingly. -Sherman On 11/07/2011 12:57 PM, Ulf Zibis wrote: > Hi Sherman, > > 2 nits again: > protected static final class Encoder extends CharsetEncoder > - If final, protected doesn't make sense, as it can't be subclassed. > (ideally this should be a compiler error) > - Where is it used? Otherwise it could be private. > > -Ulf > > > Am 07.11.2011 21:30, schrieb Xueming Shen: >> Thanks Alan, >> >> The webrev has been updated accordingly to address your comments (the >> commented out isMalformed2 has been removed, copyright updated, bugid >> added...) >> >> And thanks for Ulf for the detailed review. >> >> -Sherman >> >> On 10/28/2011 09:14 AM, Alan Bateman wrote: >>> On 28/09/2011 20:18, Xueming Shen wrote: >>>> Hi, >>>> >>>> [I combined the proposed charge for #7082884, in which no one >>>> appears to be >>>> interested:-) into this one] >>>> : >>>> >>>> http://cr.openjdk.java.net/~sherman/7096080/webrev/ >>>> >>> I don't know if you are still looking for a reviewer for this (seems >>> like Ulf has gone through this in detail, thanks Ulf). >>> >>> Overall it looks fine to me. Minor comment is that in UTF_8.java >>> then maybe isMalformed2 should be removed completely, maybe move >>> some of the comment in the decode methods. Another minor nits is >>> that the date on CESU_8.java is 2000-2010 where I assume it should >>> be 2011. In Errors.java then it might be better to just remove L196 >>> as it might confuse future maintainers. I would also suggest adding >>> the bugID to the list of bugs in the tests too as someone these >>> references are useful. >>> >>> -Alan. >> >> From Ulf.Zibis at gmx.de Mon Nov 7 21:41:59 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 07 Nov 2011 22:41:59 +0100 Subject: Codereview request for 7096080: UTF8 update and new CESU-8 charset In-Reply-To: <4EB84D95.7050502@oracle.com> References: <4E83730A.8060106@oracle.com> <4EAAD4FD.3060302@oracle.com> <4EB83FF0.40607@oracle.com> <4EB84650.1060905@gmx.de> <4EB84D95.7050502@oracle.com> Message-ID: <4EB850A7.7070905@gmx.de> I have thought that and it was easy to see, as it glowed in blue in Sdiffs. But I anyway wondered about the combination of protected with final, or is there some miracle I don't know? And the diff line is still glowing ... You can drop final as for class Decoder ;-) -Ulf Am 07.11.2011 22:28, schrieb Xueming Shen: > Hi Ulf, > > Good catch. It was the leftover of my first drift, in which CESU.de/encoder is the > subclass of the UTF8 de/encoder. > > webrev has been updated accordingly. > > -Sherman > > On 11/07/2011 12:57 PM, Ulf Zibis wrote: >> Hi Sherman, >> >> 2 nits again: >> protected static final class Encoder extends CharsetEncoder >> - If final, protected doesn't make sense, as it can't be subclassed. (ideally this should be a >> compiler error) >> - Where is it used? Otherwise it could be private. >> >> -Ulf >> >> >> Am 07.11.2011 21:30, schrieb Xueming Shen: >>> Thanks Alan, >>> >>> The webrev has been updated accordingly to address your comments (the >>> commented out isMalformed2 has been removed, copyright updated, bugid >>> added...) >>> >>> And thanks for Ulf for the detailed review. >>> >>> -Sherman >>> >>> On 10/28/2011 09:14 AM, Alan Bateman wrote: >>>> On 28/09/2011 20:18, Xueming Shen wrote: >>>>> Hi, >>>>> >>>>> [I combined the proposed charge for #7082884, in which no one appears to be >>>>> interested:-) into this one] >>>>> : >>>>> >>>>> http://cr.openjdk.java.net/~sherman/7096080/webrev/ >>>>> >>>> I don't know if you are still looking for a reviewer for this (seems like Ulf has gone through >>>> this in detail, thanks Ulf). >>>> >>>> Overall it looks fine to me. Minor comment is that in UTF_8.java then maybe isMalformed2 should >>>> be removed completely, maybe move some of the comment in the decode methods. Another minor nits >>>> is that the date on CESU_8.java is 2000-2010 where I assume it should be 2011. In Errors.java >>>> then it might be better to just remove L196 as it might confuse future maintainers. I would >>>> also suggest adding the bugID to the list of bugs in the tests too as someone these references >>>> are useful. >>>> >>>> -Alan. >>> >>> > > From xueming.shen at oracle.com Mon Nov 7 21:43:24 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 07 Nov 2011 21:43:24 +0000 Subject: hg: jdk8/tl/jdk: 7096080: UTF8 update and new CESU-8 charset; ... Message-ID: <20111107214342.E2C4047272@hg.openjdk.java.net> Changeset: 417d91754849 Author: sherman Date: 2011-11-07 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/417d91754849 7096080: UTF8 update and new CESU-8 charset 7082884: Incorrect UTF8 conversion for sequence ED 31 7082883: Incorrect UTF8 conversion for sequence fc 80 80 8f bf bf Summary: Updated UTF8 and added CESU-8 to following the latest Standard Reviewed-by: alanb ! make/java/nio/FILES_java.gmk + src/share/classes/sun/nio/cs/CESU_8.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/standard-charsets ! test/java/nio/charset/coders/Errors.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestStringCodingUTF8.java ! test/sun/nio/cs/TestUTF8.java From forax at univ-mlv.fr Mon Nov 7 21:53:28 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 07 Nov 2011 22:53:28 +0100 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> Message-ID: <4EB85358.50407@univ-mlv.fr> On 11/07/2011 09:50 PM, Brian Goetz wrote: > Wait/notify may be better than sleeping, but semaphore/latch/barrier are much better than wait/notify. Much. > > Sent from my iPhone Yeah, APIs evolve, it seems I'm to old for that s... :) R?mi > > On Nov 7, 2011, at 1:28 PM, chris hegarty wrote: > >> Hi Gary, >> >> Thanks for taking this bug. >> >> In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to coordinate between threads. So, you could completely remove the sleep(1000) from the run method and use a Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will reach a particular point before invoking stop on the group. That way, either thread can invoke stop and set the flag to prevent the other thread from invoking stop too ( if it were to get there! ). >> >> I agree with R?mi's comments about wait/notify. My comments (above) should work with well with his suggestion. Then no more nasty sleeps! >> >> Thanks, >> -Chris. >> >> On 07/11/2011 16:03, Gary Adams wrote: >>> >>> Here's another test with race conditions built into the test >>> that can be easily avoided >>> >>> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >>> intermittently >>> >>> There are at least two race conditions in the test as currently written. >>> The test uses sleeps as a way to yield time to other threads to complete >>> their >>> tasks, but this may not be sufficient on slower machines. >>> >>> The first race condition is in the starting of the test threads. >>> To ensure both threads are started, the run check for the first thread >>> should >>> also check that the second thread is not null. >>> >>> The second race condition in the main thread presumes that >>> the group stop has been issued within 3000 milliseconds. >>> A simple loop on the delay can be gated by a flag set after the group >>> stop has been issued. >>> >>> diff --git a/test/java/lang/ThreadGroup/Stop.java >>> b/test/java/lang/ThreadGroup/Stop.java >>> --- a/test/java/lang/ThreadGroup/Stop.java >>> +++ b/test/java/lang/ThreadGroup/Stop.java >>> @@ -32,6 +32,7 @@ >>> private static Thread first=null; >>> private static Thread second=null; >>> private static ThreadGroup group = new ThreadGroup(""); >>> + private static boolean groupStopped =false ; >>> >>> Stop() { >>> Thread thread = new Thread(group, this); >>> @@ -47,8 +48,11 @@ >>> while (true) { >>> try { >>> Thread.sleep(1000); // Give other thread a chance to start >>> - if (Thread.currentThread() == first) >>> + if ((Thread.currentThread() == first) >>> +&& (second != null)) { >>> + groupStopped = true; >>> group.stop(); >>> + } >>> } catch(InterruptedException e){ >>> } >>> } >>> @@ -57,7 +61,10 @@ >>> public static void main(String[] args) throws Exception { >>> for (int i=0; i<2; i++) >>> new Stop(); >>> + do { >>> Thread.sleep(3000); >>> + } while (!groupStopped) ; >>> + >>> boolean failed = second.isAlive(); >>> first.stop(); second.stop(); >>> if (failed) >>> >>> >>> From brian.goetz at oracle.com Mon Nov 7 22:01:14 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 7 Nov 2011 17:01:14 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB85358.50407@univ-mlv.fr> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85358.50407@univ-mlv.fr> Message-ID: <50F671B0-D65F-4582-B1EA-7EC9C83A36DE@oracle.com> I can recommend a good book.... Sent from my iPhone On Nov 7, 2011, at 4:53 PM, R?mi Forax wrote: > On 11/07/2011 09:50 PM, Brian Goetz wrote: >> Wait/notify may be better than sleeping, but semaphore/latch/barrier are much better than wait/notify. Much. >> >> Sent from my iPhone > > Yeah, APIs evolve, it seems I'm to old for that s... :) > > R?mi > >> >> On Nov 7, 2011, at 1:28 PM, chris hegarty wrote: >> >>> Hi Gary, >>> >>> Thanks for taking this bug. >>> >>> In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to coordinate between threads. So, you could completely remove the sleep(1000) from the run method and use a Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will reach a particular point before invoking stop on the group. That way, either thread can invoke stop and set the flag to prevent the other thread from invoking stop too ( if it were to get there! ). >>> >>> I agree with R?mi's comments about wait/notify. My comments (above) should work with well with his suggestion. Then no more nasty sleeps! >>> >>> Thanks, >>> -Chris. >>> >>> On 07/11/2011 16:03, Gary Adams wrote: >>>> >>>> Here's another test with race conditions built into the test >>>> that can be easily avoided >>>> >>>> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >>>> intermittently >>>> >>>> There are at least two race conditions in the test as currently written. >>>> The test uses sleeps as a way to yield time to other threads to complete >>>> their >>>> tasks, but this may not be sufficient on slower machines. >>>> >>>> The first race condition is in the starting of the test threads. >>>> To ensure both threads are started, the run check for the first thread >>>> should >>>> also check that the second thread is not null. >>>> >>>> The second race condition in the main thread presumes that >>>> the group stop has been issued within 3000 milliseconds. >>>> A simple loop on the delay can be gated by a flag set after the group >>>> stop has been issued. >>>> >>>> diff --git a/test/java/lang/ThreadGroup/Stop.java >>>> b/test/java/lang/ThreadGroup/Stop.java >>>> --- a/test/java/lang/ThreadGroup/Stop.java >>>> +++ b/test/java/lang/ThreadGroup/Stop.java >>>> @@ -32,6 +32,7 @@ >>>> private static Thread first=null; >>>> private static Thread second=null; >>>> private static ThreadGroup group = new ThreadGroup(""); >>>> + private static boolean groupStopped =false ; >>>> >>>> Stop() { >>>> Thread thread = new Thread(group, this); >>>> @@ -47,8 +48,11 @@ >>>> while (true) { >>>> try { >>>> Thread.sleep(1000); // Give other thread a chance to start >>>> - if (Thread.currentThread() == first) >>>> + if ((Thread.currentThread() == first) >>>> +&& (second != null)) { >>>> + groupStopped = true; >>>> group.stop(); >>>> + } >>>> } catch(InterruptedException e){ >>>> } >>>> } >>>> @@ -57,7 +61,10 @@ >>>> public static void main(String[] args) throws Exception { >>>> for (int i=0; i<2; i++) >>>> new Stop(); >>>> + do { >>>> Thread.sleep(3000); >>>> + } while (!groupStopped) ; >>>> + >>>> boolean failed = second.isAlive(); >>>> first.stop(); second.stop(); >>>> if (failed) >>>> >>>> >>>> > From david.holmes at oracle.com Mon Nov 7 22:45:29 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Nov 2011 08:45:29 +1000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> Message-ID: <4EB85F89.7050601@oracle.com> On 8/11/2011 6:50 AM, Brian Goetz wrote: > Wait/notify may be better than sleeping, but semaphore/latch/barrier are much better than wait/notify. Much. Don't be hasty. This test is using Thread.stop - which as we all know is a Very Bad Thing. You want to be very sure that anything that may be executing when the async exception hits is async-exception safe. That generally excludes all the j.u.c utilities. Gary's suggested fix is on the right track but needs a few corrections: On 8/11/2011 2:03 AM, Gary Adams wrote: > diff --git a/test/java/lang/ThreadGroup/Stop.java > b/test/java/lang/ThreadGroup/Stop.java > --- a/test/java/lang/ThreadGroup/Stop.java > +++ b/test/java/lang/ThreadGroup/Stop.java > @@ -32,6 +32,7 @@ > private static Thread first=null; > private static Thread second=null; second needs to be volatile. Also the Stop() constructor needs to set second after the thread is started, otherwise the check below may see second as non-null before it has actually started. > private static ThreadGroup group = new ThreadGroup(""); > + private static boolean groupStopped =false ; Also needs to be volatile. > Stop() { > Thread thread = new Thread(group, this); > @@ -47,8 +48,11 @@ > while (true) { > try { > Thread.sleep(1000); // Give other thread a chance to start > - if (Thread.currentThread() == first) > + if ((Thread.currentThread() == first) > + && (second != null)) { > + groupStopped = true; > group.stop(); You need to set groupStopped after group.stop() else the main thread may see it before the actual stop happens. As group.stop will throw an exception it will need to be set in a finally block. Now we could remove the sleeps and replace with wait/notify, as they are also async-safe, but there is no need. Because the sleeps are being used in a polling loop they don't have any issue with slow machines or over-loaded machines etc. The sleep logic is simpler than the corresponding wait/notify. David ----- > Sent from my iPhone > > On Nov 7, 2011, at 1:28 PM, chris hegarty wrote: > >> Hi Gary, >> >> Thanks for taking this bug. >> >> In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to coordinate between threads. So, you could completely remove the sleep(1000) from the run method and use a Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will reach a particular point before invoking stop on the group. That way, either thread can invoke stop and set the flag to prevent the other thread from invoking stop too ( if it were to get there! ). >> >> I agree with R?mi's comments about wait/notify. My comments (above) should work with well with his suggestion. Then no more nasty sleeps! >> >> Thanks, >> -Chris. >> >> On 07/11/2011 16:03, Gary Adams wrote: >>> >>> >>> Here's another test with race conditions built into the test >>> that can be easily avoided >>> >>> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >>> intermittently >>> >>> There are at least two race conditions in the test as currently written. >>> The test uses sleeps as a way to yield time to other threads to complete >>> their >>> tasks, but this may not be sufficient on slower machines. >>> >>> The first race condition is in the starting of the test threads. >>> To ensure both threads are started, the run check for the first thread >>> should >>> also check that the second thread is not null. >>> >>> The second race condition in the main thread presumes that >>> the group stop has been issued within 3000 milliseconds. >>> A simple loop on the delay can be gated by a flag set after the group >>> stop has been issued. >>> >>> diff --git a/test/java/lang/ThreadGroup/Stop.java >>> b/test/java/lang/ThreadGroup/Stop.java >>> --- a/test/java/lang/ThreadGroup/Stop.java >>> +++ b/test/java/lang/ThreadGroup/Stop.java >>> @@ -32,6 +32,7 @@ >>> private static Thread first=null; >>> private static Thread second=null; >>> private static ThreadGroup group = new ThreadGroup(""); >>> + private static boolean groupStopped =false ; >>> >>> Stop() { >>> Thread thread = new Thread(group, this); >>> @@ -47,8 +48,11 @@ >>> while (true) { >>> try { >>> Thread.sleep(1000); // Give other thread a chance to start >>> - if (Thread.currentThread() == first) >>> + if ((Thread.currentThread() == first) >>> +&& (second != null)) { >>> + groupStopped = true; >>> group.stop(); >>> + } >>> } catch(InterruptedException e){ >>> } >>> } >>> @@ -57,7 +61,10 @@ >>> public static void main(String[] args) throws Exception { >>> for (int i=0; i<2; i++) >>> new Stop(); >>> + do { >>> Thread.sleep(3000); >>> + } while (!groupStopped) ; >>> + >>> boolean failed = second.isAlive(); >>> first.stop(); second.stop(); >>> if (failed) >>> >>> >>> From david.holmes at oracle.com Mon Nov 7 22:48:02 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 08 Nov 2011 08:48:02 +1000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB82351.9020001@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> Message-ID: <4EB86022.7090806@oracle.com> On 8/11/2011 4:28 AM, chris hegarty wrote: > In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to > coordinate between threads. So, you could completely remove the > sleep(1000) from the run method and use a > Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will > reach a particular point before invoking stop on the group. That way, > either thread can invoke stop and set the flag to prevent the other > thread from invoking stop too ( if it were to get there! ). FYI for what this test is testing the requirement is that the first thread issue that group.stop(). David > I agree with R?mi's comments about wait/notify. My comments (above) > should work with well with his suggestion. Then no more nasty sleeps! > > Thanks, > -Chris. > > On 07/11/2011 16:03, Gary Adams wrote: >> >> >> Here's another test with race conditions built into the test >> that can be easily avoided >> >> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >> intermittently >> >> There are at least two race conditions in the test as currently written. >> The test uses sleeps as a way to yield time to other threads to complete >> their >> tasks, but this may not be sufficient on slower machines. >> >> The first race condition is in the starting of the test threads. >> To ensure both threads are started, the run check for the first thread >> should >> also check that the second thread is not null. >> >> The second race condition in the main thread presumes that >> the group stop has been issued within 3000 milliseconds. >> A simple loop on the delay can be gated by a flag set after the group >> stop has been issued. >> >> diff --git a/test/java/lang/ThreadGroup/Stop.java >> b/test/java/lang/ThreadGroup/Stop.java >> --- a/test/java/lang/ThreadGroup/Stop.java >> +++ b/test/java/lang/ThreadGroup/Stop.java >> @@ -32,6 +32,7 @@ >> private static Thread first=null; >> private static Thread second=null; >> private static ThreadGroup group = new ThreadGroup(""); >> + private static boolean groupStopped =false ; >> >> Stop() { >> Thread thread = new Thread(group, this); >> @@ -47,8 +48,11 @@ >> while (true) { >> try { >> Thread.sleep(1000); // Give other thread a chance to start >> - if (Thread.currentThread() == first) >> + if ((Thread.currentThread() == first) >> + && (second != null)) { >> + groupStopped = true; >> group.stop(); >> + } >> } catch(InterruptedException e){ >> } >> } >> @@ -57,7 +61,10 @@ >> public static void main(String[] args) throws Exception { >> for (int i=0; i<2; i++) >> new Stop(); >> + do { >> Thread.sleep(3000); >> + } while (!groupStopped) ; >> + >> boolean failed = second.isAlive(); >> first.stop(); second.stop(); >> if (failed) >> >> >> From tom.hawtin at oracle.com Mon Nov 7 22:56:07 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 07 Nov 2011 22:56:07 +0000 Subject: Who is on Dedoxx? In-Reply-To: <4EB7C3C7.6070001@gmx.de> References: <4EB7C3C7.6070001@gmx.de> Message-ID: <4EB86207.9050700@oracle.com> On 07/11/11 11:40, Ulf Zibis wrote: > I want to know, if there are any members of the list participating on > the Devoxx Conference next week. I shall be attending. For the third year running I shall be on holiday and not representing my employer. Tom From chris.hegarty at oracle.com Tue Nov 8 09:03:19 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Nov 2011 09:03:19 +0000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB85F89.7050601@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> Message-ID: <4EB8F057.1080905@oracle.com> On 11/ 7/11 10:45 PM, David Holmes wrote: > On 8/11/2011 6:50 AM, Brian Goetz wrote: >> Wait/notify may be better than sleeping, but semaphore/latch/barrier >> are much better than wait/notify. Much. > > Don't be hasty. This test is using Thread.stop - which as we all know is > a Very Bad Thing. You want to be very sure that anything that may be > executing when the async exception hits is async-exception safe. That > generally excludes all the j.u.c utilities. Ah yes, I should have known this. Thanks for catching David. We really need to be careful with these old tests or we could end up losing their original meaning. Gary, please ignore my previous comments. -Chris. > > Gary's suggested fix is on the right track but needs a few corrections: > > On 8/11/2011 2:03 AM, Gary Adams wrote: > > diff --git a/test/java/lang/ThreadGroup/Stop.java > > b/test/java/lang/ThreadGroup/Stop.java > > --- a/test/java/lang/ThreadGroup/Stop.java > > +++ b/test/java/lang/ThreadGroup/Stop.java > > @@ -32,6 +32,7 @@ > > private static Thread first=null; > > private static Thread second=null; > > second needs to be volatile. > > Also the Stop() constructor needs to set second after the thread is > started, otherwise the check below may see second as non-null before it > has actually started. > > > private static ThreadGroup group = new ThreadGroup(""); > > + private static boolean groupStopped =false ; > > Also needs to be volatile. > > > Stop() { > > Thread thread = new Thread(group, this); > > @@ -47,8 +48,11 @@ > > while (true) { > > try { > > Thread.sleep(1000); // Give other thread a chance to start > > - if (Thread.currentThread() == first) > > + if ((Thread.currentThread() == first) > > + && (second != null)) { > > + groupStopped = true; > > group.stop(); > > You need to set groupStopped after group.stop() else the main thread may > see it before the actual stop happens. As group.stop will throw an > exception it will need to be set in a finally block. > > Now we could remove the sleeps and replace with wait/notify, as they are > also async-safe, but there is no need. Because the sleeps are being used > in a polling loop they don't have any issue with slow machines or > over-loaded machines etc. The sleep logic is simpler than the > corresponding wait/notify. > > David > ----- > >> Sent from my iPhone >> >> On Nov 7, 2011, at 1:28 PM, chris hegarty >> wrote: >> >>> Hi Gary, >>> >>> Thanks for taking this bug. >>> >>> In similar tests I've preferred to use j.u.c.Paser/CountDownLatch to >>> coordinate between threads. So, you could completely remove the >>> sleep(1000) from the run method and use a >>> Phaser.arriveAndAwaitAdvance(). This will guarantee both threads will >>> reach a particular point before invoking stop on the group. That way, >>> either thread can invoke stop and set the flag to prevent the other >>> thread from invoking stop too ( if it were to get there! ). >>> >>> I agree with R?mi's comments about wait/notify. My comments (above) >>> should work with well with his suggestion. Then no more nasty sleeps! >>> >>> Thanks, >>> -Chris. >>> >>> On 07/11/2011 16:03, Gary Adams wrote: >>>> >>>> >>>> Here's another test with race conditions built into the test >>>> that can be easily avoided >>>> >>>> CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails >>>> intermittently >>>> >>>> There are at least two race conditions in the test as currently >>>> written. >>>> The test uses sleeps as a way to yield time to other threads to >>>> complete >>>> their >>>> tasks, but this may not be sufficient on slower machines. >>>> >>>> The first race condition is in the starting of the test threads. >>>> To ensure both threads are started, the run check for the first thread >>>> should >>>> also check that the second thread is not null. >>>> >>>> The second race condition in the main thread presumes that >>>> the group stop has been issued within 3000 milliseconds. >>>> A simple loop on the delay can be gated by a flag set after the group >>>> stop has been issued. >>>> >>>> diff --git a/test/java/lang/ThreadGroup/Stop.java >>>> b/test/java/lang/ThreadGroup/Stop.java >>>> --- a/test/java/lang/ThreadGroup/Stop.java >>>> +++ b/test/java/lang/ThreadGroup/Stop.java >>>> @@ -32,6 +32,7 @@ >>>> private static Thread first=null; >>>> private static Thread second=null; >>>> private static ThreadGroup group = new ThreadGroup(""); >>>> + private static boolean groupStopped =false ; >>>> >>>> Stop() { >>>> Thread thread = new Thread(group, this); >>>> @@ -47,8 +48,11 @@ >>>> while (true) { >>>> try { >>>> Thread.sleep(1000); // Give other thread a chance to start >>>> - if (Thread.currentThread() == first) >>>> + if ((Thread.currentThread() == first) >>>> +&& (second != null)) { >>>> + groupStopped = true; >>>> group.stop(); >>>> + } >>>> } catch(InterruptedException e){ >>>> } >>>> } >>>> @@ -57,7 +61,10 @@ >>>> public static void main(String[] args) throws Exception { >>>> for (int i=0; i<2; i++) >>>> new Stop(); >>>> + do { >>>> Thread.sleep(3000); >>>> + } while (!groupStopped) ; >>>> + >>>> boolean failed = second.isAlive(); >>>> first.stop(); second.stop(); >>>> if (failed) >>>> >>>> >>>> From gary.adams at oracle.com Tue Nov 8 13:12:17 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 08 Nov 2011 08:12:17 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB8F057.1080905@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> Message-ID: <4EB92AB1.405@oracle.com> Let's see if this captures all the comments and is a bit more robust in the face of the original race conditions mentioned. - threads are started before they are recorded in local variables - second is now volatile - stop thread group is triggered by first thread once second thread is started - main thread checks for second thread death after thread group is stopped - left in the sleep delays to yield to other threads - using wait/notify for handshake with main thread - using try/finally to ensure main thread does not check too soon after thread group stop 31 public class Stop implements Runnable { 32 private static Thread first=null; 33 private static volatile Thread second=null; 34 private static ThreadGroup group = new ThreadGroup(""); 35 private static boolean groupStopped =false ; 36 private static final Object lock = new Object(); 37 38 Stop() { 39 Thread thread = new Thread(group, this); 40 thread.start(); 41 // Record the threads after they have been started 42 if (first == null) 43 first = thread; 44 else 45 second = thread; 46 } 47 48 public void run() { 49 while (true) { 50 try { 51 // Give the other thread a chance to start 52 Thread.sleep(1000); 53 } catch(InterruptedException e) { 54 } 55 56 // When the first thread sees the second thread has been started 57 // stop the thread group. 58 if ((Thread.currentThread() == first) 59 && (second != null)) { 60 synchronized (lock) { 61 try { 62 group.stop(); 63 } finally { 64 // Signal the main thread it is time to check 65 // that the stopped thread group was successful 66 groupStopped = true; 67 lock.notifyAll(); 68 } 69 } 70 } 71 } 72 } 73 74 public static void main(String[] args) throws Exception { 75 // Launch two threads as part of the same thread group 76 for (int i = 0; i < 2; i++) 77 new Stop(); 78 79 // Wait for the thread group to be issued 80 synchronized(lock){ 81 while (!groupStopped){ 82 lock.wait(); 83 try { 84 // Give the other thread a chance to stop 85 Thread.sleep(1000); 86 } catch(InterruptedException e) { 87 } 88 } 89 } 90 91 // Check that the second thread is terminated when the 92 // first thread terminates the thread group. 93 boolean failed = second.isAlive(); 94 95 // Clean up any threads that may have not been terminated 96 first.stop(); 97 second.stop(); 98 if (failed) 99 throw new RuntimeException("Failure."); 100 } 101 } From gary.adams at oracle.com Tue Nov 8 15:35:20 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 08 Nov 2011 10:35:20 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EB8F057.1080905@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> Message-ID: <4EB94C38.5030104@oracle.com> Here's another intermittent bug that is attributed to the garbage collection of the loggers before the final static check can be applied in the test. CR#7067691 : java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently I'd like to implement the recommended solution of adding strong references to the objects being checked, so they are available for the final tests. I'd also like to add some diagnostic printouts, in case the problem shows up again we'll have some useful information about the failure. diff --git a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java --- a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java +++ b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java @@ -42,6 +42,9 @@ static String LOGGER_NAME_1 = "com.sun.management.Logger"; static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2"; static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown"; + static Logger logger1; + static Logger logger2; + static LoggingMXBeanTest testp; public static void main(String[] argv) throws Exception { MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); @@ -51,7 +54,7 @@ LoggingMXBean.class); // test LoggingMXBean proxy - LoggingMXBeanTest p = new LoggingMXBeanTest(proxy); + testp = new LoggingMXBeanTest(proxy); // check if the attributes implemented by PlatformLoggingMXBean // and LoggingMXBean return the same value @@ -59,14 +62,18 @@ ManagementFactory.getPlatformMXBean(mbs, PlatformLoggingMXBean.class); checkAttributes(proxy, mxbean); + + logger1 = null; + logger2 = null; + testp = null; } // same verification as in java/util/logging/LoggingMXBeanTest2 public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception { - Logger logger1 = Logger.getLogger( LOGGER_NAME_1 ); + logger1 = Logger.getLogger( LOGGER_NAME_1 ); logger1.setLevel(Level.FINE); - Logger logger2 = Logger.getLogger( LOGGER_NAME_2 ); + logger2 = Logger.getLogger( LOGGER_NAME_2 ); logger2.setLevel(null); /* @@ -207,6 +214,18 @@ // verify logger names List loggers1 = mxbean1.getLoggerNames(); List loggers2 = mxbean2.getLoggerNames(); + + // Print the two logger lists for diagnostic purposes + System.out.println(" : LoggingMXBean " + loggers1); + System.out.println(" : PlatformLoggingMXBean " + loggers2); + + // Print the list of logger level comparisons for diagnostic purposes + for (String logger : loggers1) { + System.out.println (" : Level (" + logger + + ", " + mxbean1.getLoggerLevel(logger) + + ", " + mxbean2.getLoggerLevel(logger) + ")"); + } + if (loggers1.size() != loggers2.size()) throw new RuntimeException("LoggerNames: unmatched number of entries"); List loggers3 = new ArrayList<>(loggers1); @@ -219,7 +238,10 @@ if (!mxbean1.getLoggerLevel(logger) .equals(mxbean2.getLoggerLevel(logger))) throw new RuntimeException( - "LoggerLevel: unmatched level for " + logger); + "LoggerLevel: unmatched level for (" + logger + + ", " + mxbean1.getLoggerLevel(logger) + + ", " + mxbean2.getLoggerLevel(logger) + ")"); + if (!mxbean1.getParentLoggerName(logger) .equals(mxbean2.getParentLoggerName(logger))) throw new RuntimeException( With this sample output added to the test log : LoggingMXBean [com.sun.management.Logger.Logger2, javax.management.snmp, global, javax.management.notification, javax.management.modelmbean, javax.management.timer, javax.management, com.sun.management.Logger, javax.management.mlet, javax.management.mbeanserver, javax.management.snmp.daemon, javax.management.relation, javax.management.monitor, javax.management.misc, ] : PlatformLoggingMXBean [com.sun.management.Logger.Logger2, javax.management.snmp, global, javax.management.notification, javax.management.modelmbean, javax.management.timer, javax.management, com.sun.management.Logger, javax.management.mlet, javax.management.mbeanserver, javax.management.snmp.daemon, javax.management.relation, javax.management.monitor, javax.management.misc, ] : Level (com.sun.management.Logger.Logger2, SEVERE, SEVERE) : Level (javax.management.snmp, , ) : Level (global, , ) : Level (javax.management.notification, , ) : Level (javax.management.modelmbean, , ) : Level (javax.management.timer, , ) : Level (javax.management, , ) : Level (com.sun.management.Logger, , ) : Level (javax.management.mlet, , ) : Level (javax.management.mbeanserver, , ) : Level (javax.management.snmp.daemon, , ) : Level (javax.management.relation, , ) : Level (javax.management.monitor, , ) : Level (javax.management.misc, , ) : Level (, INFO, INFO) From forax at univ-mlv.fr Tue Nov 8 15:54:27 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 08 Nov 2011 16:54:27 +0100 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB92AB1.405@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB92AB1.405@oracle.com> Message-ID: <4EB950B3.5060100@univ-mlv.fr> On 11/08/2011 02:12 PM, Gary Adams wrote: > Let's see if this captures all the comments and > is a bit more robust in the face of the original > race conditions mentioned. > - threads are started before they are recorded in local variables > - second is now volatile > - stop thread group is triggered by first thread once second > thread is started > - main thread checks for second thread death after thread group is > stopped > - left in the sleep delays to yield to other threads > - using wait/notify for handshake with main thread > - using try/finally to ensure main thread does not check too soon > after thread group stop I really don't like the thread.start() in the middle of the constructor. In fact, we don't really need to initialize first and second in the constructor of Stop. I propose: public class Stop implements Runnable { private static boolean groupStopped =false ; private static final Object lock = new Object(); private static final Thread first; private static final Thread second; static { ThreadGroup group = new ThreadGroup(""); first = new Thread(group, new Stop()); second = new Thread(group, new Stop()); } In that case, the is no constructor in Stop because the default one is Ok. with this initialization sequence, first and second are never null, so the check line 59 is useless. And in main(), the two threads are started like this public static void main(String[] args) throws Exception { // Launch two threads as part of the same thread group first.start(); second.start(); ... I find this code far more readable. cheers, R?mi > > 31 public class Stop implements Runnable { > 32 private static Thread first=null; > 33 private static volatile Thread second=null; > 34 private static ThreadGroup group = new ThreadGroup(""); > 35 private static boolean groupStopped =false ; > 36 private static final Object lock = new Object(); > 37 > 38 Stop() { > 39 Thread thread = new Thread(group, this); > 40 thread.start(); > 41 // Record the threads after they have been started > 42 if (first == null) > 43 first = thread; > 44 else > 45 second = thread; > 46 } > 47 > 48 public void run() { > 49 while (true) { > 50 try { > 51 // Give the other thread a chance to start > 52 Thread.sleep(1000); > 53 } catch(InterruptedException e) { > 54 } > 55 > 56 // When the first thread sees the second thread > has been started > 57 // stop the thread group. > 58 if ((Thread.currentThread() == first) > 59 && (second != null)) { > 60 synchronized (lock) { > 61 try { > 62 group.stop(); > 63 } finally { > 64 // Signal the main thread it is time > to check > 65 // that the stopped thread group was > successful > 66 groupStopped = true; > 67 lock.notifyAll(); > 68 } > 69 } > 70 } > 71 } > 72 } > 73 > 74 public static void main(String[] args) throws Exception { > 75 // Launch two threads as part of the same thread group > 76 for (int i = 0; i < 2; i++) > 77 new Stop(); > 78 > 79 // Wait for the thread group to be issued > 80 synchronized(lock){ > 81 while (!groupStopped){ > 82 lock.wait(); > 83 try { > 84 // Give the other thread a chance to stop > 85 Thread.sleep(1000); > 86 } catch(InterruptedException e) { > 87 } > 88 } > 89 } > 90 > 91 // Check that the second thread is terminated when the > 92 // first thread terminates the thread group. > 93 boolean failed = second.isAlive(); > 94 > 95 // Clean up any threads that may have not been > terminated > 96 first.stop(); > 97 second.stop(); > 98 if (failed) > 99 throw new RuntimeException("Failure."); > 100 } > 101 } > From chris.hegarty at oracle.com Tue Nov 8 15:52:47 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 08 Nov 2011 15:52:47 +0000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB92AB1.405@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB92AB1.405@oracle.com> Message-ID: <4EB9504F.7030202@oracle.com> Wow Gary, this is much better ( no thanks to my comments ;-) ) Nearly there now, please bear with us. I'll try again to be constructive (but you may need to wait for David to come back online to confirm my comments below :-) ) 1) 'first' also needs to be volatile since it is set in one thread and accessed in another (outside of a sync block, or without any barrier). 2) I wouldn't just swallow the InterruptedException. jtreg uses thread interrupts to kill/interrupt a test that has used more than it's allotted time. I think it best to just throw them up the stack where possible, and wrap them in an Error or RuntimeException in run(). But either way allow the thread to be interruptible and complete execution. Thanks again for taking this issue, -Chris. On 11/ 8/11 01:12 PM, Gary Adams wrote: > Let's see if this captures all the comments and > is a bit more robust in the face of the original > race conditions mentioned. > - threads are started before they are recorded in local variables > - second is now volatile > - stop thread group is triggered by first thread once second thread is > started > - main thread checks for second thread death after thread group is stopped > - left in the sleep delays to yield to other threads > - using wait/notify for handshake with main thread > - using try/finally to ensure main thread does not check too soon > after thread group stop > > 31 public class Stop implements Runnable { > 32 private static Thread first=null; > 33 private static volatile Thread second=null; > 34 private static ThreadGroup group = new ThreadGroup(""); > 35 private static boolean groupStopped =false ; > 36 private static final Object lock = new Object(); > 37 > 38 Stop() { > 39 Thread thread = new Thread(group, this); > 40 thread.start(); > 41 // Record the threads after they have been started > 42 if (first == null) > 43 first = thread; > 44 else > 45 second = thread; > 46 } > 47 > 48 public void run() { > 49 while (true) { > 50 try { > 51 // Give the other thread a chance to start > 52 Thread.sleep(1000); > 53 } catch(InterruptedException e) { > 54 } > 55 > 56 // When the first thread sees the second thread has been started > 57 // stop the thread group. > 58 if ((Thread.currentThread() == first) > 59 && (second != null)) { > 60 synchronized (lock) { > 61 try { > 62 group.stop(); > 63 } finally { > 64 // Signal the main thread it is time to check > 65 // that the stopped thread group was successful > 66 groupStopped = true; > 67 lock.notifyAll(); > 68 } > 69 } > 70 } > 71 } > 72 } > 73 > 74 public static void main(String[] args) throws Exception { > 75 // Launch two threads as part of the same thread group > 76 for (int i = 0; i < 2; i++) > 77 new Stop(); > 78 > 79 // Wait for the thread group to be issued > 80 synchronized(lock){ > 81 while (!groupStopped){ > 82 lock.wait(); > 83 try { > 84 // Give the other thread a chance to stop > 85 Thread.sleep(1000); > 86 } catch(InterruptedException e) { > 87 } > 88 } > 89 } > 90 > 91 // Check that the second thread is terminated when the > 92 // first thread terminates the thread group. > 93 boolean failed = second.isAlive(); > 94 > 95 // Clean up any threads that may have not been terminated > 96 first.stop(); > 97 second.stop(); > 98 if (failed) > 99 throw new RuntimeException("Failure."); > 100 } > 101 } > From Ulf.Zibis at gmx.de Tue Nov 8 18:40:55 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 08 Nov 2011 19:40:55 +0100 Subject: Who is on Dedoxx? In-Reply-To: <4EB83150.1090408@oracle.com> References: <4EB7C3C7.6070001@gmx.de> <4EB82F79.6090407@reini.net> <4EB83150.1090408@oracle.com> Message-ID: <4EB977B7.1050003@gmx.de> Hi Dalibor, thanks for the invitation. Can one explain me what BOF stands for? The Devoxx is totally overbooked, so no chance to come. Anyway I do not have an employer sponsering me the fee. :-( Thanks for all your answers, Ulf Am 07.11.2011 20:28, schrieb Dalibor Topic: > On 11/7/11 8:20 PM, Patrick Reinhart wrote: >> Hi Ulf, >> >> I will be there.. > There will be an OpenJDK Community BOF [0] at Devoxx on Tuesday, so if you're there, do stop by! > > cheers, > dalibor topic > > [0] http://devoxx.com/display/DV11/The+OpenJDK+Community+BOF > From dalibor.topic at oracle.com Tue Nov 8 18:49:07 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 08 Nov 2011 19:49:07 +0100 Subject: Who is on Dedoxx? In-Reply-To: <4EB977B7.1050003@gmx.de> References: <4EB7C3C7.6070001@gmx.de> <4EB82F79.6090407@reini.net> <4EB83150.1090408@oracle.com> <4EB977B7.1050003@gmx.de> Message-ID: <4EB979A3.7000209@oracle.com> On 11/8/11 7:40 PM, Ulf Zibis wrote: > Can one explain me what BOF stands for? https://secure.wikimedia.org/wikipedia/en/wiki/Birds_of_a_Feather_%28computing%29 cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From jonathan.gibbons at oracle.com Tue Nov 8 19:52:10 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 08 Nov 2011 19:52:10 +0000 Subject: hg: jdk8/tl/langtools: 6921494: provide way to print javac tree tag values Message-ID: <20111108195215.4E9F747298@hg.openjdk.java.net> Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java From jonathan.gibbons at oracle.com Wed Nov 9 01:29:18 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Nov 2011 01:29:18 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111109012923.97C05472A1@hg.openjdk.java.net> Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/36553cb94345 7108668: allow Log to be initialized and used earlier Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: ae361e7f435a Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ae361e7f435a 7108669: cleanup Log methods for direct printing to streams Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java From weijun.wang at oracle.com Wed Nov 9 01:51:19 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 09 Nov 2011 01:51:19 +0000 Subject: hg: jdk8/tl/jdk: 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Message-ID: <20111109015130.0CF22472A2@hg.openjdk.java.net> Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f410b91caf45 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java From david.holmes at oracle.com Wed Nov 9 03:17:54 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Nov 2011 13:17:54 +1000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB950B3.5060100@univ-mlv.fr> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB92AB1.405@oracle.com> <4EB950B3.5060100@univ-mlv.fr> Message-ID: <4EB9F0E2.1090602@oracle.com> Gary, I agree with Remi - the initialization process can be simplified as shown. As long as first is created and started first it should do the job. You should test that the updated test still fails on a JDK without the fix. I'm a little concerned about the change to wait/notify due to the fact the notifyAll happens while the ThreadDeath is pending. But this should either work or not work, I don't think it will introduce further obscure races (though with Thread.stop I don't take anything for granted). David On 9/11/2011 1:54 AM, R?mi Forax wrote: > On 11/08/2011 02:12 PM, Gary Adams wrote: >> Let's see if this captures all the comments and >> is a bit more robust in the face of the original >> race conditions mentioned. >> - threads are started before they are recorded in local variables >> - second is now volatile >> - stop thread group is triggered by first thread once second thread is >> started >> - main thread checks for second thread death after thread group is >> stopped >> - left in the sleep delays to yield to other threads >> - using wait/notify for handshake with main thread >> - using try/finally to ensure main thread does not check too soon >> after thread group stop > > I really don't like the thread.start() in the middle of the constructor. > In fact, we don't really need to initialize first and second in the > constructor of Stop. > > I propose: > public class Stop implements Runnable { > private static boolean groupStopped =false ; > private static final Object lock = new Object(); > > private static final Thread first; > private static final Thread second; > static { > ThreadGroup group = new ThreadGroup(""); > first = new Thread(group, new Stop()); > second = new Thread(group, new Stop()); > } > > In that case, the is no constructor in Stop because > the default one is Ok. > > with this initialization sequence, first and second are never null, > so the check line 59 is useless. > > And in main(), the two threads are started like this > public static void main(String[] args) throws Exception { > // Launch two threads as part of the same thread group > first.start(); > second.start(); > ... > > > I find this code far more readable. > > cheers, > R?mi > >> >> 31 public class Stop implements Runnable { >> 32 private static Thread first=null; >> 33 private static volatile Thread second=null; >> 34 private static ThreadGroup group = new ThreadGroup(""); >> 35 private static boolean groupStopped =false ; >> 36 private static final Object lock = new Object(); >> 37 >> 38 Stop() { >> 39 Thread thread = new Thread(group, this); >> 40 thread.start(); >> 41 // Record the threads after they have been started >> 42 if (first == null) >> 43 first = thread; >> 44 else >> 45 second = thread; >> 46 } >> 47 >> 48 public void run() { >> 49 while (true) { >> 50 try { >> 51 // Give the other thread a chance to start >> 52 Thread.sleep(1000); >> 53 } catch(InterruptedException e) { >> 54 } >> 55 >> 56 // When the first thread sees the second thread has been started >> 57 // stop the thread group. >> 58 if ((Thread.currentThread() == first) >> 59 && (second != null)) { >> 60 synchronized (lock) { >> 61 try { >> 62 group.stop(); >> 63 } finally { >> 64 // Signal the main thread it is time to check >> 65 // that the stopped thread group was successful >> 66 groupStopped = true; >> 67 lock.notifyAll(); >> 68 } >> 69 } >> 70 } >> 71 } >> 72 } >> 73 >> 74 public static void main(String[] args) throws Exception { >> 75 // Launch two threads as part of the same thread group >> 76 for (int i = 0; i < 2; i++) >> 77 new Stop(); >> 78 >> 79 // Wait for the thread group to be issued >> 80 synchronized(lock){ >> 81 while (!groupStopped){ >> 82 lock.wait(); >> 83 try { >> 84 // Give the other thread a chance to stop >> 85 Thread.sleep(1000); >> 86 } catch(InterruptedException e) { >> 87 } >> 88 } >> 89 } >> 90 >> 91 // Check that the second thread is terminated when the >> 92 // first thread terminates the thread group. >> 93 boolean failed = second.isAlive(); >> 94 >> 95 // Clean up any threads that may have not been terminated >> 96 first.stop(); >> 97 second.stop(); >> 98 if (failed) >> 99 throw new RuntimeException("Failure."); >> 100 } >> 101 } >> > From mandy.chung at oracle.com Wed Nov 9 04:13:03 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Nov 2011 20:13:03 -0800 Subject: Garbage collection race condition before final checks In-Reply-To: <4EB94C38.5030104@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> Message-ID: <4EB9FDCF.9020909@oracle.com> Gary, Thanks for picking up this bug and fixing this intermittent issue. PlatformLoggingMXBeanTest.java in the same directory has the same issue. It'd be good to fix that with the same CR. These tests were copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't looked in details but I wonder why the test/java/util/logging tests don't have this intermittent issue and I suspect it holds a strong reference. A couple comment to the fix: On 11/8/2011 7:35 AM, Gary Adams wrote: > > diff --git > a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > --- > a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > +++ > b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java Please add the CR number to @bug tag. > @@ -42,6 +42,9 @@ > static String LOGGER_NAME_1 = "com.sun.management.Logger"; > static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2"; > static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown"; > + static Logger logger1; > + static Logger logger2; It'd be good to add a comment why you want to keep a strong reference to the logger. Minor nit: could make them as instance variables as they are part of the LoggingMXBeanTest instance. > + static LoggingMXBeanTest testp; > > public static void main(String[] argv) throws Exception { > MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); > @@ -51,7 +54,7 @@ > LoggingMXBean.class); > > // test LoggingMXBean proxy > - LoggingMXBeanTest p = new LoggingMXBeanTest(proxy); > + testp = new LoggingMXBeanTest(proxy); Could we make checkAttributes as an instance method to LoggingMXBeanTest object so that you don't need the static variable? > > // check if the attributes implemented by PlatformLoggingMXBean > // and LoggingMXBean return the same value > @@ -59,14 +62,18 @@ > ManagementFactory.getPlatformMXBean(mbs, > PlatformLoggingMXBean.class); > > checkAttributes(proxy, mxbean); > + > + logger1 = null; > + logger2 = null; > + testp = null; With the above suggested change, I think these 3 lines are not needed. > } > > // same verification as in java/util/logging/LoggingMXBeanTest2 > public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception { > > - Logger logger1 = Logger.getLogger( LOGGER_NAME_1 ); > + logger1 = Logger.getLogger( LOGGER_NAME_1 ); > logger1.setLevel(Level.FINE); > - Logger logger2 = Logger.getLogger( LOGGER_NAME_2 ); > + logger2 = Logger.getLogger( LOGGER_NAME_2 ); > logger2.setLevel(null); > > /* > @@ -207,6 +214,18 @@ > // verify logger names > List loggers1 = mxbean1.getLoggerNames(); > List loggers2 = mxbean2.getLoggerNames(); > + > + // Print the two logger lists for diagnostic purposes > + System.out.println(" : LoggingMXBean " + loggers1); > + System.out.println(" : PlatformLoggingMXBean " + loggers2); > + > + // Print the list of logger level comparisons for diagnostic > purposes > + for (String logger : loggers1) { > + System.out.println (" : Level (" + logger > + + ", " + mxbean1.getLoggerLevel(logger) > + + ", " + mxbean2.getLoggerLevel(logger) + ")"); > + } > It might be good to keep these diagnostic message to be printed only when it throws an exception? Extra diagnostic information is good but just want to keep the volume of traces reasonable not to make the output harder to use. Thanks again for fixing it. Mandy From weijun.wang at oracle.com Wed Nov 9 07:51:52 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 09 Nov 2011 07:51:52 +0000 Subject: hg: jdk8/tl/jdk: 7109096: keytool -genkeypair needn't call -selfcert Message-ID: <20111109075203.1D76F472A5@hg.openjdk.java.net> Changeset: 52be75d060f9 Author: weijun Date: 2011-11-09 15:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52be75d060f9 7109096: keytool -genkeypair needn't call -selfcert Reviewed-by: xuelei ! src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java From luchsh at linux.vnet.ibm.com Wed Nov 9 08:01:51 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 09 Nov 2011 16:01:51 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EB37782.9010507@oracle.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> Message-ID: <4EBA336F.9060004@linux.vnet.ibm.com> On 11/04/2011 01:26 PM, David Holmes wrote: > On 4/11/2011 2:53 PM, David Holmes wrote: >> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>> 10.03. The difference still exists. >>> >>> Solaris 10: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:04:45 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 13:04:53 JST 2011 >>> >>> Ubuntu 10.04: >>> $ unset TZ >>> $ date >>> Fri Nov 4 13:05:50 JST 2011 >>> $ TZ="" date >>> Fri Nov 4 04:05:55 UTC 2011 >>> >>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>> still looks up the system default. >> >> I have to take back my comment regarding this not seeming to be platform >> specific code - it is highly platform specific! It seems that on Linux >> we are happy to report a TZ of "" but not so on Solaris. I presume this >> is an attempt to keep Java's use of TZ consistent with how other apps >> handle it on that platform. (environ(5) gives a little insight on >> Solaris as to how TZ is used.) >> >> So the key thing here is to not disturb the existing behaviour on either >> linux or Solaris - which suggests the original patch. That said I'm not >> convinced - given this is so platform specific - that simply treating >> non-linux the same as Solaris is a reasonable thing to do. I think it >> would be useful to see what the BSD/OSX port(s) had to do with this code >> - if anything. > > To answer my own queries BSD/OSX does > > 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > 512 if (tz == NULL) { > 513 #else > 514 #ifdef __solaris__ > 515 if (tz == NULL || *tz == '\0') { > 516 #endif > 517 #endif > > so the suggested patch would at least not interfere. > > Anyway this needs input from other core-libs folk. I didn't intend to > get quite so heavily involved. ;-) > > David > ----- > > > >> David >> ----- >> >> >>> Thanks, >>> Masayoshi >>> >>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>> Hi Masayoshi, >>>> >>>> I did find some references about date-time related functions / TZ >>>> variables on Linux but got only a few about Solaris, so could not see >>>> any differences between those two platforms about the changes >>>> described in my patch. Have you got any links or references about >>>> these differences? I'm interested in it and may update the patch again >>>> after reading them. >>>> >>>> Thanks a lot! >>>> - Jonathan >>>> >>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>> Hi Jonathan, >>>>> >>>>> IIRC, the difference came from some behavioral difference between the >>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>> written looooong ago. The difference may no longer exist. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>> Hi core-libs-dev, >>>>>>>>> >>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>> line >>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>> currently >>>>>>>>> working on, such as AIX. >>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>> the >>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>> 'patch.diff'. I >>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>> about >>>>>>>>> this modification? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>> mail >>>>>>>> content directly. >>>>>>>> >>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>> 19:06:53 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>> 13:43:47 >>>>>>>> 2011 +0800 >>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>> #ifdef __linux__ >>>>>>>> if (tz == NULL) { >>>>>>>> #else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> #endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>> >>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>> following would be platform neutral: >>>>>>> >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>> Hi David, >>>>>> >>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>> be retrieved from that environment variable. >>>>>> So I changed the patch to this, >>>>>> >>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>> 2011 -0700 >>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>> 2011 +0800 >>>>>> @@ -623,13 +623,7 @@ >>>>>> >>>>>> tz = getenv("TZ"); >>>>>> >>>>>> -#ifdef __linux__ >>>>>> - if (tz == NULL) { >>>>>> -#else >>>>>> -#ifdef __solaris__ >>>>>> if (tz == NULL || *tz == '\0') { >>>>>> -#endif >>>>>> -#endif >>>>>> tz = getPlatformTimeZoneID(); >>>>>> freetz = tz; >>>>>> } >>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Regards >>>>>>>> - Jonathan Lu >>>>>> Regards >>>>>> >>>>>> - Jonathan >>>>>> >>>> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here has some ideas about this issue. -Jonathan From Alan.Bateman at oracle.com Wed Nov 9 09:08:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Nov 2011 09:08:28 +0000 Subject: Garbage collection race condition before final checks In-Reply-To: <4EB94C38.5030104@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> Message-ID: <4EBA430C.6000400@oracle.com> On 08/11/2011 15:35, Gary Adams wrote: > Here's another intermittent bug that is attributed > to the garbage collection of the loggers before the > final static check can be applied in the test. > > CR#7067691 : > java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > failing intermittently I agree with Mandy that it would be great to do a quick audit of the other logging (and PlatformLoggingMXBean) tests to see if we have similar issues. I should explain that one reason why these test failures may not have been observed in the past is because most people ran jtreg in its default mode (called othervm mode, where each tests runs in its own VM). Nowadays we run the tests via the make file or use jtreg -agentvm so that tests are running sequentially in an agent VM. Not all areas can run in agent VM mode yet but for the areas that do then we get a good speed up as the startup cost is eliminated and also it's possible to have a pool of agent VMs to make use of all cores when doing test runs (-agentvm -concurrency:auto for example). However agent VM makes things less predictable and for these tests it means that the GC will be unpredictable which is why this test was failing only very intermittently. Anyway, the changes look fine to me. I agree with Mandy that many logger1 and logger2 could be instance variables. I would suggest "proxy" or something more readable rather than "testp" for the LoggingMXBean proxy. I also agree with Mandy's comment about adding the @bug. -Alan. From lvjing at linux.vnet.ibm.com Wed Nov 9 08:57:04 2011 From: lvjing at linux.vnet.ibm.com (Jing Lv) Date: Wed, 09 Nov 2011 16:57:04 +0800 Subject: A method with return type size_t returns negative value In-Reply-To: <4E282A6E.7010305@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> Message-ID: <4EBA4060.6030706@linux.vnet.ibm.com> Hello Alan, (Sorry that haven't check this for months) I check with the bug 7030624 but see no progress now. What's the current status? Shall we go on with a simple patch to fix the problem? On 2011/7/21 21:32, Alan Bateman wrote: > Jing LV wrote: >> Ping, anyone notice this? :) >> My plan is that we'd search all source to find all kinds of such >> issues, and then refine them in a uniform solution. If jint is not >> good enough, how about ssize_t? > ACK, saw your mails and will get back to you soon on this. > > -Alan From gary.adams at oracle.com Wed Nov 9 10:46:18 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 05:46:18 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EB9FDCF.9020909@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> Message-ID: <4EBA59FA.70007@oracle.com> On 11/8/11 11:13 PM, Mandy Chung wrote: > Gary, > > Thanks for picking up this bug and fixing this intermittent issue. > PlatformLoggingMXBeanTest.java in the same directory has the same > issue. It'd be good to fix that with the same CR. These tests were > copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't > looked in details but I wonder why the test/java/util/logging tests > don't have this intermittent issue and I suspect it holds a strong > reference. I'll take a look at the other tests to see if they suffer from the same issue. I was able to force the intermittent bugs to reproduce quickly with a strategic GC in the worst possible place. > > A couple comment to the fix: > > On 11/8/2011 7:35 AM, Gary Adams wrote: >> >> diff --git >> a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> --- >> a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> +++ >> b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java > > Please add the CR number to @bug tag. Will do. > >> @@ -42,6 +42,9 @@ >> static String LOGGER_NAME_1 = "com.sun.management.Logger"; >> static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2"; >> static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown"; >> + static Logger logger1; >> + static Logger logger2; > > It'd be good to add a comment why you want to keep a strong reference > to the logger. Minor nit: could make them as instance variables as > they are part of the LoggingMXBeanTest instance. I'll give it a try. > >> + static LoggingMXBeanTest testp; >> >> public static void main(String[] argv) throws Exception { >> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); >> @@ -51,7 +54,7 @@ >> LoggingMXBean.class); >> >> // test LoggingMXBean proxy >> - LoggingMXBeanTest p = new LoggingMXBeanTest(proxy); >> + testp = new LoggingMXBeanTest(proxy); > > Could we make checkAttributes as an instance method to > LoggingMXBeanTest object so that you don't need the static variable? My preference is to leave a test as intact as possible from how the original test was written. e.g. do the minimum required to make the test reliable. These regression tests are meant to confirm that a particular issue does not slip back into the code base. Changing checkAttributes to be an instance method is not essential to getting the test to work properly. Better to get 10 intermittent tests to work reliably rather than get 1 test polished to perfection. $.02 > >> >> // check if the attributes implemented by PlatformLoggingMXBean >> // and LoggingMXBean return the same value >> @@ -59,14 +62,18 @@ >> ManagementFactory.getPlatformMXBean(mbs, >> PlatformLoggingMXBean.class); >> >> checkAttributes(proxy, mxbean); >> + >> + logger1 = null; >> + logger2 = null; >> + testp = null; > > With the above suggested change, I think these 3 lines are not needed. OK >> } >> >> // same verification as in java/util/logging/LoggingMXBeanTest2 >> public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception { >> >> - Logger logger1 = Logger.getLogger( LOGGER_NAME_1 ); >> + logger1 = Logger.getLogger( LOGGER_NAME_1 ); >> logger1.setLevel(Level.FINE); >> - Logger logger2 = Logger.getLogger( LOGGER_NAME_2 ); >> + logger2 = Logger.getLogger( LOGGER_NAME_2 ); >> logger2.setLevel(null); >> >> /* >> @@ -207,6 +214,18 @@ >> // verify logger names >> List loggers1 = mxbean1.getLoggerNames(); >> List loggers2 = mxbean2.getLoggerNames(); >> + >> + // Print the two logger lists for diagnostic purposes >> + System.out.println(" : LoggingMXBean " + loggers1); >> + System.out.println(" : PlatformLoggingMXBean " + loggers2); >> + >> + // Print the list of logger level comparisons for diagnostic >> purposes >> + for (String logger : loggers1) { >> + System.out.println (" : Level (" + logger >> + + ", " + mxbean1.getLoggerLevel(logger) >> + + ", " + mxbean2.getLoggerLevel(logger) + ")"); >> + } >> > > It might be good to keep these diagnostic message to be printed only > when it throws an exception? Extra diagnostic information is good but > just want to keep the volume of traces reasonable not to make the > output harder to use. We can probably delete the diagnostic output, now that the problem is clearly identified. > > Thanks again for fixing it. Alan pointed out a pile of "teststabilization" bugs that have been tagged. I'll see if any of those were suffering from the same issue found here. > Mandy From gary.adams at oracle.com Wed Nov 9 10:55:00 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 05:55:00 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBA430C.6000400@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EBA430C.6000400@oracle.com> Message-ID: <4EBA5C04.9010704@oracle.com> On 11/9/11 4:08 AM, Alan Bateman wrote: > On 08/11/2011 15:35, Gary Adams wrote: >> Here's another intermittent bug that is attributed >> to the garbage collection of the loggers before the >> final static check can be applied in the test. >> >> CR#7067691 : >> java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java >> failing intermittently > I agree with Mandy that it would be great to do a quick audit of the > other logging (and PlatformLoggingMXBean) tests to see if we have > similar issues. I should explain that one reason why these test > failures may not have been observed in the past is because most people > ran jtreg in its default mode (called othervm mode, where each tests > runs in its own VM). Nowadays we run the tests via the make file or > use jtreg -agentvm so that tests are running sequentially in an agent > VM. Not all areas can run in agent VM mode yet but for the areas that > do then we get a good speed up as the startup cost is eliminated and > also it's possible to have a pool of agent VMs to make use of all > cores when doing test runs (-agentvm -concurrency:auto for example). > However agent VM makes things less predictable and for these tests it > means that the GC will be unpredictable which is why this test was > failing only very intermittently. > > Anyway, the changes look fine to me. I agree with Mandy that many > logger1 and logger2 could be instance variables. I would suggest > "proxy" or something more readable rather than "testp" for the > LoggingMXBean proxy. I also agree with Mandy's comment about adding > the @bug. > > -Alan. "proxy" was my first choice, but that was already used for another local variable. The original variable was just "p", but that seemed unwise for a global variable name. ... lather & rinse From Alan.Bateman at oracle.com Wed Nov 9 11:30:27 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Nov 2011 11:30:27 +0000 Subject: Fwd: Re: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBA5A18.4000603@geomatys.fr> References: <4EBA5A18.4000603@geomatys.fr> Message-ID: <4EBA6453.5000807@oracle.com> Does anyone have cycles to review and sponsor the "Core" and "SQL" clean-ups? They should be trivial to review and push as one change-set, leaving the client area changes for review on the 2d or other list. -Alan. -------- Original Message -------- Subject: Re: Miscellaneous minor patches: javadoc typos, javac warnings, etc. Date: Wed, 09 Nov 2011 11:46:48 +0100 From: Martin Desruisseaux Organization: Geomatys CC: jdk8-dev at openjdk.java.net Hello all It took me a while, but I finally posted the patches that I submitted last month as webrev pages. I tried to split them according different groups (core, Java2D...) to the best of my knowledge: http://webrev.geomatys.com/ I also signed the Oracle Contributor Agreement (OCA) and send it by email to oracle-ca_us at oracle.com. In the core classes, most patches can be grouped in two categories: * Documentation fixes (Class, Attributes) * Avoid creation of unnecessary temporary objects (AssertionError, Float, Double) The only real bug fix is in Java 2D (AffineTransform.hashCode() inconsistent with equals(Object) when some coefficients mix positive and negative zeros). However I'm not yet registered on the Java2D mailing list. Should I register on the mailing list of each group for which I may propose a patch? Regards, Martin From Lance.Andersen at oracle.com Wed Nov 9 12:41:31 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 9 Nov 2011 07:41:31 -0500 Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBA6453.5000807@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> Message-ID: <16BDA5C8-0E4E-49A5-9566-63E7E02789C4@oracle.com> I looked at the core and sql changes and they are fine. I will great a bug for these and submit the change-set. Best lance On Nov 9, 2011, at 6:30 AM, Alan Bateman wrote: > > Does anyone have cycles to review and sponsor the "Core" and "SQL" clean-ups? They should be trivial to review and push as one change-set, leaving the client area changes for review on the 2d or other list. > > -Alan. > > -------- Original Message -------- > Subject: Re: Miscellaneous minor patches: javadoc typos, javac warnings, etc. > Date: Wed, 09 Nov 2011 11:46:48 +0100 > From: Martin Desruisseaux > Organization: Geomatys > CC: jdk8-dev at openjdk.java.net > > > > Hello all > > It took me a while, but I finally posted the patches that I submitted last month > as webrev pages. I tried to split them according different groups (core, > Java2D...) to the best of my knowledge: > > http://webrev.geomatys.com/ > > I also signed the Oracle Contributor Agreement (OCA) and send it by email to > oracle-ca_us at oracle.com. > > In the core classes, most patches can be grouped in two categories: > > * Documentation fixes (Class, Attributes) > * Avoid creation of unnecessary temporary objects (AssertionError, Float, Double) > > > The only real bug fix is in Java 2D (AffineTransform.hashCode() inconsistent > with equals(Object) when some coefficients mix positive and negative zeros). > However I'm not yet registered on the Java2D mailing list. Should I register on > the mailing list of each group for which I may propose a patch? > > Regards, > > Martin > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Wed Nov 9 14:55:10 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Nov 2011 14:55:10 +0000 Subject: Code Review 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Message-ID: <4EBA944E.5070803@oracle.com> According to the specification for BlockingQueue.drainTo(Collection c, int maxElements), this method should return "the number of elements transferred". However the implementation of this method for LinkedBlockingQueue and LinkedBlockingDeque when given a negative number returns the given negative number. Invoking drainTo(Collection, int) with a value of 0 or less should simply return 0. This change has been pulled from Doug Lea's CVS and I have already reviewed it. Sending to the list for further scrutiny/review. Webrev: http://cr.openjdk.java.net/~chegar/7107516/webrev.00/webrev/ Thanks, -Chris. From mike.duigou at oracle.com Wed Nov 9 16:44:10 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 9 Nov 2011 08:44:10 -0800 Subject: Code Review 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative In-Reply-To: <4EBA944E.5070803@oracle.com> References: <4EBA944E.5070803@oracle.com> Message-ID: The change looks good. The creation of node instances could use diamond. ie. Node node = new Node(e); could be : Node node = new Node<>(e); Mike On Nov 9 2011, at 06:55 , Chris Hegarty wrote: > > According to the specification for BlockingQueue.drainTo(Collection c, int maxElements), this method should return "the number of elements transferred". However the implementation of this method for LinkedBlockingQueue and LinkedBlockingDeque when given a negative number returns the given negative number. > > Invoking drainTo(Collection, int) with a value of 0 or less should simply return 0. > > This change has been pulled from Doug Lea's CVS and I have already reviewed it. Sending to the list for further scrutiny/review. > > Webrev: > http://cr.openjdk.java.net/~chegar/7107516/webrev.00/webrev/ > > Thanks, > -Chris. From chris.hegarty at oracle.com Wed Nov 9 17:03:47 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 09 Nov 2011 17:03:47 +0000 Subject: Code Review 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative In-Reply-To: References: <4EBA944E.5070803@oracle.com> Message-ID: <4EBAB273.4070104@oracle.com> On 09/11/2011 16:44, Mike Duigou wrote: > The change looks good. > > The creation of node instances could use diamond. ie. Yes, this was my initial reaction too. Since Doug's CVS is also built with JDK6 I guess he cannot take advantage of new 7 features. I just tried to keep in sync rather than making a special exception for our downstream copy of this code. I guess going forward we may have to think about how we can use newer features in this area, but I think Doug will have this problem too. -Chris. > > Node node = new Node(e); > > could be : > > Node node = new Node<>(e); > > Mike > > On Nov 9 2011, at 06:55 , Chris Hegarty wrote: > >> >> According to the specification for BlockingQueue.drainTo(Collection c, int maxElements), this method should return "the number of elements transferred". However the implementation of this method for LinkedBlockingQueue and LinkedBlockingDeque when given a negative number returns the given negative number. >> >> Invoking drainTo(Collection, int) with a value of 0 or less should simply return 0. >> >> This change has been pulled from Doug Lea's CVS and I have already reviewed it. Sending to the list for further scrutiny/review. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/7107516/webrev.00/webrev/ >> >> Thanks, >> -Chris. > From philip.race at oracle.com Wed Nov 9 17:37:13 2011 From: philip.race at oracle.com (Phil Race) Date: Wed, 09 Nov 2011 09:37:13 -0800 Subject: Fwd: Re: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBA6453.5000807@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> Message-ID: <4EBABA49.8020101@oracle.com> Martin, Please do register on 2d-dev and propose the 2D changes there. The hashcode change definitely needs discussion, I think there may be views on the NaN comparison as my understanding is that this is supposed to always be not equal. Could be a spec. change for the class if its admissible. Further discussion on this should be on 2d-dev. -phil. PS this is such an unrelated set of changes, I am not sure it should be under one CR, even for 2D. On 11/9/2011 3:30 AM, Alan Bateman wrote: > > Does anyone have cycles to review and sponsor the "Core" and "SQL" > clean-ups? They should be trivial to review and push as one > change-set, leaving the client area changes for review on the 2d or > other list. > > -Alan. > > -------- Original Message -------- > Subject: Re: Miscellaneous minor patches: javadoc typos, javac > warnings, etc. > Date: Wed, 09 Nov 2011 11:46:48 +0100 > From: Martin Desruisseaux > Organization: Geomatys > CC: jdk8-dev at openjdk.java.net > > > > Hello all > > It took me a while, but I finally posted the patches that I submitted > last month > as webrev pages. I tried to split them according different groups (core, > Java2D...) to the best of my knowledge: > > http://webrev.geomatys.com/ > > I also signed the Oracle Contributor Agreement (OCA) and send it by > email to > oracle-ca_us at oracle.com. > > In the core classes, most patches can be grouped in two categories: > > * Documentation fixes (Class, Attributes) > * Avoid creation of unnecessary temporary objects (AssertionError, > Float, Double) > > > The only real bug fix is in Java 2D (AffineTransform.hashCode() > inconsistent > with equals(Object) when some coefficients mix positive and negative > zeros). > However I'm not yet registered on the Java2D mailing list. Should I > register on > the mailing list of each group for which I may propose a patch? > > Regards, > > Martin > > From martin.desruisseaux at geomatys.fr Wed Nov 9 18:40:55 2011 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Wed, 09 Nov 2011 19:40:55 +0100 Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBABA49.8020101@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> <4EBABA49.8020101@oracle.com> Message-ID: <4EBAC937.8000606@geomatys.fr> Hello Phil Le 09/11/11 18:37, Phil Race a ?crit : > Please do register on 2d-dev and propose the 2D changes there. Registration done, I will post in a few minutes. > The hashcode change > definitely needs discussion, I think there may be views on the NaN comparison > as my > understanding is that this is supposed to always be not equal. The proposed change is consistent with the java.lang.Double.equals(Object) behavior. It seems to me the only way to be compliant with the reflexivity contract documented in Object.equals javadoc, apart doing a "if (other == this) return true" check. Maybe whatever full compliance with Object.equals is strongly desired or not can be a question for the core group? I would like to note that incomplete compliance may be a risk when AffineTransform (or any other object) is used as keys in Hashtable: in current implementation, if an AffineTransform object with at least one NaN value is added in a Hashtable, it is impossible to remove it by a call to Hashtable.remove(Object) (we can still remove it by Iterator.remove()). (Note: my example uses Hashtable instead of HashMap because HashMap has a clever implementation that check for object references before to invoke Object.equals, which invalidate my argument. However not all implementations are that safe). > PS this is such an unrelated set of changes, I am not sure it should be under > one CR, even for 2D. Actually this is 8 distinct change sets, but webrev merged all my change sets in a single one. Since it is the first time I'm using webrev, I'm probably not using it in the right way. But I still have the 8 distinct changes set on my local Mercurial clone, so I can probably recreate new webrev pages if I learn how to use webrev better... Regards, Martin From gary.adams at oracle.com Wed Nov 9 19:09:34 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 14:09:34 -0500 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EB9504F.7030202@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB92AB1.405@oracle.com> <4EB9504F.7030202@oracle.com> Message-ID: <4EBACFEE.3010004@oracle.com> Captured the latest round of comments - more readable initialization - allow sleep interruption to terminate main thread - added current CR# to @bug tag 24 /** 25 * @test 26 * @bug 4176355 7084033 27 * @summary Stopping a ThreadGroup that contains the current thread has 28 * unpredictable results. 29 */ 30 31 public class Stop implements Runnable { 32 private static boolean groupStopped = false ; 33 private static final Object lock = new Object(); 34 35 private static final ThreadGroup group = new ThreadGroup(""); 36 private static final Thread first = new Thread(group, new Stop()); 37 private static final Thread second = new Thread(group, new Stop()); 38 39 public void run() { 40 while (true) { 41 // Give the other thread a chance to start 42 try { 43 Thread.sleep(1000); 44 } catch (InterruptedException e) { 45 } 46 47 // When the first thread runs, it will stop the group. 48 if (Thread.currentThread() == first) { 49 synchronized (lock) { 50 try { 51 group.stop(); 52 } finally { 53 // Signal the main thread it is time to check 54 // that the stopped thread group was successful 55 groupStopped = true; 56 lock.notifyAll(); 57 } 58 } 59 } 60 } 61 } 62 63 public static void main(String[] args) throws Exception { 64 // Launch two threads as part of the same thread group 65 second.start(); 66 first.start(); 67 68 // Wait for the thread group stop to be issued 69 synchronized(lock){ 70 while (!groupStopped) { 71 lock.wait(); 72 // Give the other thread a chance to stop 73 Thread.sleep(1000); 74 } 75 } 76 77 // Check that the second thread is terminated when the 78 // first thread terminates the thread group. 79 boolean failed = second.isAlive(); 80 81 // Clean up any threads that may have not been terminated 82 first.stop(); 83 second.stop(); 84 if (failed) 85 throw new RuntimeException("Failure."); 86 } 87 } From gary.adams at oracle.com Wed Nov 9 19:21:33 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 14:21:33 -0500 Subject: Timing bugs In-Reply-To: <4EB3EA75.2050006@oracle.com> References: <4EB3EA75.2050006@oracle.com> Message-ID: <4EBAD2BD.3050900@oracle.com> Here's an update diff for the elapsed time check. - added current CR# to @bug tag - moved capture of start time to after creation of the latches so only the schedule*() and the await() calls are included in the elapsed time check. jdk/test/java/util/Timer/Args.java /* * @test - * @bug 6571655 6571881 6574585 6571297 + * @bug 6571655 6571881 6574585 6571297 6731620 * @summary Test various args to task scheduling methods */ @@ -92,19 +92,21 @@ new F(){void f(){ t.scheduleAtFixedRate(x, (Date)null, 42); }} ); - final long start = System.currentTimeMillis(); - final Date past = new Date(start - 10500); final CountDownLatch y1 = new CountDownLatch(1); final CountDownLatch y2 = new CountDownLatch(1); final CountDownLatch y3 = new CountDownLatch(11); + final long start = System.currentTimeMillis(); + final Date past = new Date(start - 10500); + final long elapsed; schedule( t, counter(y1), past); schedule( t, counter(y2), past, 1000); scheduleAtFixedRate(t, counter(y3), past, 1000); y3.await(); y1.await(); y2.await(); - System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); - check(System.currentTimeMillis() - start < 500); + elapsed = System.currentTimeMillis() - start; + System.out.printf("elapsed=%d%n", elapsed); + check(elapsed < 500); t.cancel(); On 11/ 4/11 09:36 AM, Gary Adams wrote: > I've started to look at timing related bugs that have been open > for a while, but have not had sufficient priority to make it to the > top of the list of bugs to be fixed. Thought I'd start with some > low hanging fruit with simple bug fixes. > > 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the > execution time of System.out.printf > > This seems like a simply problem to avoid two calls to get the current time > and to eliminated the time to process the print statement > from the evaluation of the test elapsed time. > > Replacing this sequence ; > > System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); > check(System.currentTimeMillis() - start < 500); > > with > > elapsed = System.currentTimeMillis() - start; > System.out.printf("elapsed=%d%n", elapsed); > check(elapsed < 500); > > I plan to test the fix on a 300MHz linux/arm device. > I'll provide a proper webrev as soon as I have author rights > confirmed. I'm looking for reviewer and a committer, > once I get the fix tested locally. > > Thanks > Gary Adams > From gary.adams at oracle.com Wed Nov 9 19:26:05 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 14:26:05 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBA430C.6000400@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EBA430C.6000400@oracle.com> Message-ID: <4EBAD3CD.20904@oracle.com> Here's an updated diff : - added current CR# to the @bug tag - made logger1 and logger2 instance variables - renamed test instance variable lmxbeantest - removed excessive diagnostic print outs --- a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java +++ b/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java @@ -23,7 +23,7 @@ /* * @test - * @bug 7024172 + * @bug 7024172 7067691 * @summary Test if proxy for PlatformLoggingMXBean is equivalent * to proxy for LoggingMXBean * @@ -43,6 +43,13 @@ static String LOGGER_NAME_2 = "com.sun.management.Logger.Logger2"; static String UNKNOWN_LOGGER_NAME = "com.sun.management.Unknown"; + // These instance variables prevent premature logger garbage collection + // See getLogger() weak reference warnings. + Logger logger1; + Logger logger2; + + static LoggingMXBeanTest lmxbeantest; + public static void main(String[] argv) throws Exception { MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); LoggingMXBean proxy = @@ -51,7 +58,7 @@ LoggingMXBean.class); // test LoggingMXBean proxy - LoggingMXBeanTest p = new LoggingMXBeanTest(proxy); + lmxbeantest = new LoggingMXBeanTest(proxy); // check if the attributes implemented by PlatformLoggingMXBean // and LoggingMXBean return the same value @@ -59,14 +66,16 @@ ManagementFactory.getPlatformMXBean(mbs, PlatformLoggingMXBean.class); checkAttributes(proxy, mxbean); + + lmxbeantest = null; } // same verification as in java/util/logging/LoggingMXBeanTest2 public LoggingMXBeanTest(LoggingMXBean mbean) throws Exception { - Logger logger1 = Logger.getLogger( LOGGER_NAME_1 ); + logger1 = Logger.getLogger( LOGGER_NAME_1 ); logger1.setLevel(Level.FINE); - Logger logger2 = Logger.getLogger( LOGGER_NAME_2 ); + logger2 = Logger.getLogger( LOGGER_NAME_2 ); logger2.setLevel(null); /* @@ -207,6 +216,7 @@ // verify logger names List loggers1 = mxbean1.getLoggerNames(); List loggers2 = mxbean2.getLoggerNames(); + if (loggers1.size() != loggers2.size()) throw new RuntimeException("LoggerNames: unmatched number of entries"); List loggers3 = new ArrayList<>(loggers1); @@ -219,7 +229,10 @@ if (!mxbean1.getLoggerLevel(logger) .equals(mxbean2.getLoggerLevel(logger))) throw new RuntimeException( - "LoggerLevel: unmatched level for " + logger); + "LoggerLevel: unmatched level for (" + logger + + ", " + mxbean1.getLoggerLevel(logger) + + ", " + mxbean2.getLoggerLevel(logger) + ")"); + if (!mxbean1.getParentLoggerName(logger) .equals(mxbean2.getParentLoggerName(logger))) throw new RuntimeException( On 11/ 9/11 04:08 AM, Alan Bateman wrote: > On 08/11/2011 15:35, Gary Adams wrote: >> Here's another intermittent bug that is attributed >> to the garbage collection of the loggers before the >> final static check can be applied in the test. >> >> CR#7067691 : >> java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing >> intermittently > I agree with Mandy that it would be great to do a quick audit of the other > logging (and PlatformLoggingMXBean) tests to see if we have similar issues. I > should explain that one reason why these test failures may not have been > observed in the past is because most people ran jtreg in its default mode > (called othervm mode, where each tests runs in its own VM). Nowadays we run > the tests via the make file or use jtreg -agentvm so that tests are running > sequentially in an agent VM. Not all areas can run in agent VM mode yet but > for the areas that do then we get a good speed up as the startup cost is > eliminated and also it's possible to have a pool of agent VMs to make use of > all cores when doing test runs (-agentvm -concurrency:auto for example). > However agent VM makes things less predictable and for these tests it means > that the GC will be unpredictable which is why this test was failing only very > intermittently. > > Anyway, the changes look fine to me. I agree with Mandy that many logger1 and > logger2 could be instance variables. I would suggest "proxy" or something more > readable rather than "testp" for the LoggingMXBean proxy. I also agree with > Mandy's comment about adding the @bug. > > -Alan. From gary.adams at oracle.com Wed Nov 9 19:36:17 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Nov 2011 14:36:17 -0500 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EB73871.2090408@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> <4EB4693D.9070705@oracle.com> <4EB73871.2090408@oracle.com> Message-ID: <4EBAD631.30102@oracle.com> Here's a revised diff for the KillThread timing problem : - added current CR# to @bug tag - capture the thread from the timer task - wait for the timertask thread to be visible to the main thread then join the thread before fall through to attempt the second timertask schedule call. diff --git a/test/java/util/Timer/KillThread.java b/test/java/util/Timer/KillThread.java --- a/test/java/util/Timer/KillThread.java +++ b/test/java/util/Timer/KillThread.java @@ -23,7 +23,7 @@ /* * @test - * @bug 4288198 + * @bug 4288198 6818464 * @summary Killing a Timer thread causes the Timer to fail silently on * subsequent use. */ @@ -31,21 +31,27 @@ import java.util.*; public class KillThread { + static Thread tdThread; public static void main (String[] args) throws Exception { + tdThread = null; Timer t = new Timer(); // Start a mean event that kills the timer thread t.schedule(new TimerTask() { public void run() { + tdThread = Thread.currentThread(); throw new ThreadDeath(); } }, 0); // Wait for mean event to do the deed and thread to die. try { + do { Thread.sleep(100); + } while(tdThread == null); } catch(InterruptedException e) { } + tdThread.join(); // Try to start another event try { On 11/ 6/11 08:46 PM, David Holmes wrote: > On 5/11/2011 8:37 AM, Alan Bateman wrote: >> On 04/11/2011 15:52, Gary Adams wrote: >>> : >>> >>> I'll attempt a simple fix for the KillThread case by replacing : >>> >>> Thread.sleep(100); >>> >>> with a simple loop >>> >>> do { >>> Thread.sleep(100); >>> } while (waiting); >>> >>> where the TimerTask runnable will clear the flag >>> with "waiting = false " once it has been launched. >>> >> I don't think this will guarantee that the timer thread will have >> terminated before the main thread schedules the second event. I think >> this test would be robust if you capture a reference to the timer thread >> in the first task and have the main thread wait or poll until it has a >> reference to the thread. Once it has a reference to the thread then it >> can wait for it to terminate before attempting to schedule the second task. > > Agreed. As soon as waiting is set we can switch back to the main thread and > proceed to the next phase of the test - but the timer thread is still alive at > that point. If the issue is checking for thread termination then we must track > that directly. > > David > ----- > >> -Alan. From Alan.Bateman at oracle.com Wed Nov 9 21:18:23 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Nov 2011 21:18:23 +0000 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBAD3CD.20904@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EBA430C.6000400@oracle.com> <4EBAD3CD.20904@oracle.com> Message-ID: <4EBAEE1F.8050800@oracle.com> On 09/11/2011 19:26, Gary Adams wrote: > Here's an updated diff : > - added current CR# to the @bug tag > - made logger1 and logger2 instance variables > - renamed test instance variable lmxbeantest > - removed excessive diagnostic print outs Looks fine to me except that we might find a better name than "lmxbeantest", also the setting to null can be removed. One of us needs to push this, listing you as contributor. Mandy or Dan - are you taking it? -Alan. From mandy.chung at oracle.com Wed Nov 9 23:50:40 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 09 Nov 2011 15:50:40 -0800 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBAEE1F.8050800@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EBA430C.6000400@oracle.com> <4EBAD3CD.20904@oracle.com> <4EBAEE1F.8050800@oracle.com> Message-ID: <4EBB11D0.20400@oracle.com> On 11/9/2011 1:18 PM, Alan Bateman wrote: > On 09/11/2011 19:26, Gary Adams wrote: >> Here's an updated diff : >> - added current CR# to the @bug tag >> - made logger1 and logger2 instance variables >> - renamed test instance variable lmxbeantest >> - removed excessive diagnostic print outs > Looks fine to me except that we might find a better name than > "lmxbeantest", also the setting to null can be removed. > > One of us needs to push this, listing you as contributor. Mandy or Dan > - are you taking it? > I will help take this one. Gary, can you also fix PlatformLoggingMXBeanTest.java? We should fix these 2 tests for this bug. Thanks Mandy From david.holmes at oracle.com Thu Nov 10 05:34:58 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 15:34:58 +1000 Subject: Code Review 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative In-Reply-To: <4EBAB273.4070104@oracle.com> References: <4EBA944E.5070803@oracle.com> <4EBAB273.4070104@oracle.com> Message-ID: <4EBB6282.3040100@oracle.com> On 10/11/2011 3:03 AM, Chris Hegarty wrote: > On 09/11/2011 16:44, Mike Duigou wrote: >> The change looks good. >> >> The creation of node instances could use diamond. ie. > > Yes, this was my initial reaction too. > > Since Doug's CVS is also built with JDK6 I guess he cannot take > advantage of new 7 features. I just tried to keep in sync rather than > making a special exception for our downstream copy of this code. I guess > going forward we may have to think about how we can use newer features > in this area, but I think Doug will have this problem too. Good point - I was going to make the same comment as Mike. I assume this change was to remove a warning. Changes look good to me. David ----- > -Chris. > >> >> Node node = new Node(e); >> >> could be : >> >> Node node = new Node<>(e); >> >> Mike >> >> On Nov 9 2011, at 06:55 , Chris Hegarty wrote: >> >>> >>> According to the specification for BlockingQueue.drainTo(Collection >>> c, int maxElements), this method should return "the number of >>> elements transferred". However the implementation of this method for >>> LinkedBlockingQueue and LinkedBlockingDeque when given a negative >>> number returns the given negative number. >>> >>> Invoking drainTo(Collection, int) with a value of 0 or less should >>> simply return 0. >>> >>> This change has been pulled from Doug Lea's CVS and I have already >>> reviewed it. Sending to the list for further scrutiny/review. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/7107516/webrev.00/webrev/ >>> >>> Thanks, >>> -Chris. >> From david.holmes at oracle.com Thu Nov 10 07:04:49 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 17:04:49 +1000 Subject: Race condition in ThreadGroup stop test In-Reply-To: <4EBACFEE.3010004@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB92AB1.405@oracle.com> <4EB9504F.7030202@oracle.com> <4EBACFEE.3010004@oracle.com> Message-ID: <4EBB7791.6090500@oracle.com> Gary, Did you test that this still fails on a JDK without the fix? AFAICS you must start the threads in the correct order so that in the original bad code the first thread in the ThreadGroup that would be stopped is "first". Hence 64 // Launch two threads as part of the same thread group 65 second.start(); 66 first.start(); needs to be reversed. It is the start() that adds the Thread to the ThreadGroup's internal array. David On 10/11/2011 5:09 AM, Gary Adams wrote: > Captured the latest round of comments > - more readable initialization > - allow sleep interruption to terminate main thread > - added current CR# to @bug tag > > 24 /** > 25 * @test > 26 * @bug 4176355 7084033 > 27 * @summary Stopping a ThreadGroup that contains the current thread has > 28 * unpredictable results. > 29 */ > 30 > 31 public class Stop implements Runnable { > 32 private static boolean groupStopped = false ; > 33 private static final Object lock = new Object(); > 34 > 35 private static final ThreadGroup group = new ThreadGroup(""); > 36 private static final Thread first = new Thread(group, new Stop()); > 37 private static final Thread second = new Thread(group, new Stop()); > 38 > 39 public void run() { > 40 while (true) { > 41 // Give the other thread a chance to start > 42 try { > 43 Thread.sleep(1000); > 44 } catch (InterruptedException e) { > 45 } > 46 > 47 // When the first thread runs, it will stop the group. > 48 if (Thread.currentThread() == first) { > 49 synchronized (lock) { > 50 try { > 51 group.stop(); > 52 } finally { > 53 // Signal the main thread it is time to check > 54 // that the stopped thread group was successful > 55 groupStopped = true; > 56 lock.notifyAll(); > 57 } > 58 } > 59 } > 60 } > 61 } > 62 > 63 public static void main(String[] args) throws Exception { > 64 // Launch two threads as part of the same thread group > 65 second.start(); > 66 first.start(); > 67 > 68 // Wait for the thread group stop to be issued > 69 synchronized(lock){ > 70 while (!groupStopped) { > 71 lock.wait(); > 72 // Give the other thread a chance to stop > 73 Thread.sleep(1000); > 74 } > 75 } > 76 > 77 // Check that the second thread is terminated when the > 78 // first thread terminates the thread group. > 79 boolean failed = second.isAlive(); > 80 > 81 // Clean up any threads that may have not been terminated > 82 first.stop(); > 83 second.stop(); > 84 if (failed) > 85 throw new RuntimeException("Failure."); > 86 } > 87 } > From david.holmes at oracle.com Thu Nov 10 07:22:19 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 17:22:19 +1000 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EBAD631.30102@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> <4EB4693D.9070705@oracle.com> <4EB73871.2090408@oracle.com> <4EBAD631.30102@oracle.com> Message-ID: <4EBB7BAB.4050801@oracle.com> Hi Gary, On 10/11/2011 5:36 AM, Gary Adams wrote: > Here's a revised diff for the KillThread timing problem : > - added current CR# to @bug tag I don't think that is correct. AFAIK the @bug indicates what bug this test is testing the fix for, not which bugs modified the test. (Ditto for your other test fixes). Alan: can you confirm? Thanks. > public class KillThread { > + static Thread tdThread; Must be volatile as its value is being communicated from the timer thread to the main thread. > public static void main (String[] args) throws Exception { > + tdThread = null; Not necessary - static field is null by default. > Timer t = new Timer(); > > // Start a mean event that kills the timer thread > t.schedule(new TimerTask() { > public void run() { > + tdThread = Thread.currentThread(); > throw new ThreadDeath(); > } > }, 0); > > // Wait for mean event to do the deed and thread to die. > try { > + do { > Thread.sleep(100); > + } while(tdThread == null); > } catch(InterruptedException e) { > } Minor nit: You didn't introduce this, but catching IE is unnecessary as main can let it propagate. With the updated code in the unlikely event it occurred you might then go and invoke join() on a null reference. Aside: it would be good if whomever is going to do the commits for you could assist with publishing webrevs for these changes. Thanks, David ----- > + tdThread.join(); > > // Try to start another event > try { > > > On 11/ 6/11 08:46 PM, David Holmes wrote: >> On 5/11/2011 8:37 AM, Alan Bateman wrote: >>> On 04/11/2011 15:52, Gary Adams wrote: >>>> : >>>> >>>> I'll attempt a simple fix for the KillThread case by replacing : >>>> >>>> Thread.sleep(100); >>>> >>>> with a simple loop >>>> >>>> do { >>>> Thread.sleep(100); >>>> } while (waiting); >>>> >>>> where the TimerTask runnable will clear the flag >>>> with "waiting = false " once it has been launched. >>>> >>> I don't think this will guarantee that the timer thread will have >>> terminated before the main thread schedules the second event. I think >>> this test would be robust if you capture a reference to the timer thread >>> in the first task and have the main thread wait or poll until it has a >>> reference to the thread. Once it has a reference to the thread then it >>> can wait for it to terminate before attempting to schedule the second >>> task. >> >> Agreed. As soon as waiting is set we can switch back to the main >> thread and proceed to the next phase of the test - but the timer >> thread is still alive at that point. If the issue is checking for >> thread termination then we must track that directly. >> >> David >> ----- >> >>> -Alan. > From david.holmes at oracle.com Thu Nov 10 07:36:24 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 17:36:24 +1000 Subject: Timing bugs In-Reply-To: <4EBAD2BD.3050900@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EBAD2BD.3050900@oracle.com> Message-ID: <4EBB7EF8.5060306@oracle.com> Hi Gary, Functional changes look okay to me. Thanks, David On 10/11/2011 5:21 AM, Gary Adams wrote: > Here's an update diff for the elapsed time check. > - added current CR# to @bug tag > - moved capture of start time to after creation of the latches > so only the schedule*() and the await() calls are included > in the elapsed time check. > > jdk/test/java/util/Timer/Args.java > > /* > * @test > - * @bug 6571655 6571881 6574585 6571297 > + * @bug 6571655 6571881 6574585 6571297 6731620 > * @summary Test various args to task scheduling methods > */ > > @@ -92,19 +92,21 @@ > new F(){void f(){ t.scheduleAtFixedRate(x, (Date)null, 42); }} > ); > > - final long start = System.currentTimeMillis(); > - final Date past = new Date(start - 10500); > final CountDownLatch y1 = new CountDownLatch(1); > final CountDownLatch y2 = new CountDownLatch(1); > final CountDownLatch y3 = new CountDownLatch(11); > + final long start = System.currentTimeMillis(); > + final Date past = new Date(start - 10500); > + final long elapsed; > schedule( t, counter(y1), past); > schedule( t, counter(y2), past, 1000); > scheduleAtFixedRate(t, counter(y3), past, 1000); > y3.await(); > y1.await(); > y2.await(); > - System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); > - check(System.currentTimeMillis() - start < 500); > + elapsed = System.currentTimeMillis() - start; > + System.out.printf("elapsed=%d%n", elapsed); > + check(elapsed < 500); > > t.cancel(); > > > > > On 11/ 4/11 09:36 AM, Gary Adams wrote: >> I've started to look at timing related bugs that have been open >> for a while, but have not had sufficient priority to make it to the >> top of the list of bugs to be fixed. Thought I'd start with some >> low hanging fruit with simple bug fixes. >> >> 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about >> the execution time of System.out.printf >> >> This seems like a simply problem to avoid two calls to get the current >> time >> and to eliminated the time to process the print statement >> from the evaluation of the test elapsed time. >> >> Replacing this sequence ; >> >> System.out.printf("elapsed=%d%n", System.currentTimeMillis() - start); >> check(System.currentTimeMillis() - start < 500); >> >> with >> >> elapsed = System.currentTimeMillis() - start; >> System.out.printf("elapsed=%d%n", elapsed); >> check(elapsed < 500); >> >> I plan to test the fix on a 300MHz linux/arm device. >> I'll provide a proper webrev as soon as I have author rights >> confirmed. I'm looking for reviewer and a committer, >> once I get the fix tested locally. >> >> Thanks >> Gary Adams >> > From Alan.Bateman at oracle.com Thu Nov 10 09:29:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Nov 2011 09:29:01 +0000 Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <16BDA5C8-0E4E-49A5-9566-63E7E02789C4@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> <16BDA5C8-0E4E-49A5-9566-63E7E02789C4@oracle.com> Message-ID: <4EBB995D.8070206@oracle.com> On 09/11/2011 12:41, Lance Andersen - Oracle wrote: > I looked at the core and sql changes and they are fine. > > I will great a bug for these and submit the change-set. > Thanks Lance. I quickly scanned the changes in the Core and SQL webrevs and they looks fine to me. Joe might want to look at the Float and Double changes, might be more consistent if constructors were "this.value = ...". -Alan. From chris.hegarty at oracle.com Thu Nov 10 09:46:18 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 10 Nov 2011 09:46:18 +0000 Subject: Code Review 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative In-Reply-To: <4EBB6282.3040100@oracle.com> References: <4EBA944E.5070803@oracle.com> <4EBAB273.4070104@oracle.com> <4EBB6282.3040100@oracle.com> Message-ID: <4EBB9D6A.5060900@oracle.com> On 10/11/2011 05:34, David Holmes wrote: > On 10/11/2011 3:03 AM, Chris Hegarty wrote: >> On 09/11/2011 16:44, Mike Duigou wrote: >>> The change looks good. >>> >>> The creation of node instances could use diamond. ie. >> >> Yes, this was my initial reaction too. >> >> Since Doug's CVS is also built with JDK6 I guess he cannot take >> advantage of new 7 features. I just tried to keep in sync rather than >> making a special exception for our downstream copy of this code. I guess >> going forward we may have to think about how we can use newer features >> in this area, but I think Doug will have this problem too. > > Good point - I was going to make the same comment as Mike. I assume this > change was to remove a warning. Yes, sorry I forgot to mention this in the original mail. I just noticed these warnings when rebuilding and though it best to drag in these simple changes to fix them. > Changes look good to me. Thanks David, -Chris. > > David > ----- > >> -Chris. >> >>> >>> Node node = new Node(e); >>> >>> could be : >>> >>> Node node = new Node<>(e); >>> >>> Mike >>> >>> On Nov 9 2011, at 06:55 , Chris Hegarty wrote: >>> >>>> >>>> According to the specification for BlockingQueue.drainTo(Collection >>>> c, int maxElements), this method should return "the number of >>>> elements transferred". However the implementation of this method for >>>> LinkedBlockingQueue and LinkedBlockingDeque when given a negative >>>> number returns the given negative number. >>>> >>>> Invoking drainTo(Collection, int) with a value of 0 or less should >>>> simply return 0. >>>> >>>> This change has been pulled from Doug Lea's CVS and I have already >>>> reviewed it. Sending to the list for further scrutiny/review. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~chegar/7107516/webrev.00/webrev/ >>>> >>>> Thanks, >>>> -Chris. >>> From gary.adams at oracle.com Thu Nov 10 11:50:17 2011 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 10 Nov 2011 06:50:17 -0500 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EBB7BAB.4050801@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> <4EB4693D.9070705@oracle.com> <4EB73871.2090408@oracle.com> <4EBAD631.30102@oracle.com> <4EBB7BAB.4050801@oracle.com> Message-ID: <4EBBBA79.8030000@oracle.com> On 11/10/11 2:22 AM, David Holmes wrote: > > Aside: it would be good if whomever is going to do the commits for you > could assist with publishing webrevs for these changes. There was a bulk request to add Vivian's team to the openjdk authors list that may have taken a longer route by way of Bob to Mark. I'll gladly post webrevs to java.net as soon as the administration tasks have been completed. From david.holmes at oracle.com Thu Nov 10 12:05:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Nov 2011 22:05:14 +1000 Subject: Race condition in TimerTask KillThread test In-Reply-To: <4EBBBA79.8030000@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB40A21.2080105@oracle.com> <4EB4693D.9070705@oracle.com> <4EB73871.2090408@oracle.com> <4EBAD631.30102@oracle.com> <4EBB7BAB.4050801@oracle.com> <4EBBBA79.8030000@oracle.com> Message-ID: <4EBBBDFA.7060409@oracle.com> On 10/11/2011 9:50 PM, Gary Adams wrote: > On 11/10/11 2:22 AM, David Holmes wrote: >> >> Aside: it would be good if whomever is going to do the commits for you >> could assist with publishing webrevs for these changes. > There was a bulk request to add Vivian's team to the openjdk > authors list that may have taken a longer route by way of Bob > to Mark. I'll gladly post webrevs to java.net as soon as the > administration tasks have been completed. I was mistakenly thinking you had to be a Committer to get the openJDK user name etc, but thankfully that is not the case. David From chris.hegarty at oracle.com Thu Nov 10 12:23:07 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 10 Nov 2011 12:23:07 +0000 Subject: hg: jdk8/tl/jdk: 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Message-ID: <20111110122328.26002472E2@hg.openjdk.java.net> Changeset: d6a5da5f6ba0 Author: dl Date: 2011-11-10 12:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6a5da5f6ba0 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Reviewed-by: chegar, mduigou, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java From gary.adams at oracle.com Thu Nov 10 14:41:10 2011 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 10 Nov 2011 09:41:10 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EB9FDCF.9020909@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> Message-ID: <4EBBE286.10109@oracle.com> On 11/ 8/11 11:13 PM, Mandy Chung wrote: > > > Thanks for picking up this bug and fixing this intermittent issue. > PlatformLoggingMXBeanTest.java in the same directory has the same issue. It'd > be good to fix that with the same CR. These tests were copied from > test/java/util/logging/LoggingMXBeanTest.java. I haven't looked in details > but I wonder why the test/java/util/logging tests don't have this intermittent > issue and I suspect it holds a strong reference. I attempted to break PlatformLoggingMXBeanTest.java with a generous application of GC calls, but I could not get it to fail in the same manner as the other test. It may be failing due to a different condition. From joe.darcy at oracle.com Thu Nov 10 15:24:10 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 10 Nov 2011 07:24:10 -0800 Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBB995D.8070206@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> <16BDA5C8-0E4E-49A5-9566-63E7E02789C4@oracle.com> <4EBB995D.8070206@oracle.com> Message-ID: <4EBBEC9A.3080300@oracle.com> Hello, On 11/10/2011 1:29 AM, Alan Bateman wrote: > On 09/11/2011 12:41, Lance Andersen - Oracle wrote: >> I looked at the core and sql changes and they are fine. >> >> I will great a bug for these and submit the change-set. >> > Thanks Lance. I quickly scanned the changes in the Core and SQL > webrevs and they looks fine to me. Joe might want to look at the Float > and Double changes, might be more consistent if constructors were > "this.value = ...". > The Float and Double changes look fine. I don't know why the constructors were coded up that way; I double checked the history and they have been that way since before the transitions to Mercurial. Writing the constructors as "this.value = " would be fine too. -Joe From martin.desruisseaux at geomatys.fr Thu Nov 10 15:38:50 2011 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Thu, 10 Nov 2011 16:38:50 +0100 Subject: Miscellaneous minor patches: javadoc typos, javac warnings, etc. In-Reply-To: <4EBBEC9A.3080300@oracle.com> References: <4EBA5A18.4000603@geomatys.fr> <4EBA6453.5000807@oracle.com> <16BDA5C8-0E4E-49A5-9566-63E7E02789C4@oracle.com> <4EBB995D.8070206@oracle.com> <4EBBEC9A.3080300@oracle.com> Message-ID: <4EBBF00A.4080202@geomatys.fr> Le 10/11/11 16:24, Joe Darcy a ?crit : > The Float and Double changes look fine. I don't know why the constructors > were coded up that way; Maybe because the Float(String) / Double(String) constructors were coded in Java 1.0, while the parseFloat(String) / parseDouble(String) methods were added (at least in public API) only in Java 1.2 and someone forgot to revisit the constructors at that time... Martin From michael.x.mcmahon at oracle.com Thu Nov 10 16:25:42 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 10 Nov 2011 16:25:42 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111110162624.AB781472EE@hg.openjdk.java.net> Changeset: 0ccfb35cce26 Author: michaelm Date: 2011-11-10 15:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ccfb35cce26 7110484: HttpServer.stop() not closing selector Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: e5d65a583c15 Author: michaelm Date: 2011-11-10 15:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5d65a583c15 Merge From lance.andersen at oracle.com Thu Nov 10 16:42:39 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 10 Nov 2011 16:42:39 +0000 Subject: hg: jdk8/tl/jdk: 7110111: Minor Java SE javadoc & Constructor clean up Message-ID: <20111110164249.AEEAF472EF@hg.openjdk.java.net> Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/830d2e46023a 7110111: Minor Java SE javadoc & Constructor clean up Reviewed-by: alanb, darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/util/jar/Attributes.java From Alan.Bateman at oracle.com Thu Nov 10 19:25:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Nov 2011 19:25:26 +0000 Subject: code review request : 7091388:Regular unexplained npe's from corba libs after system has been running for days In-Reply-To: <4EB7C414.5040403@oracle.com> References: <4EB7C414.5040403@oracle.com> Message-ID: <4EBC2526.9030502@oracle.com> On 07/11/2011 11:42, Se?n Coffey wrote: > > currently not live on bugs.sun.com but hope to get it up there shortly : > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7091388 > > I'm porting fix for 7091388 forward to JDK8 (and then 7u) > > This is a fix in the CDRInputStream_1_0.close()/ > CDROutputStream_1_0.close() methods where shared buffers may be > incorrectly closed out if the System.identityHashCode method > incorrectly identify two buffers as being equal. > > Fix is to use the "==" operator to test if buffers are equal instead > of System.identityHashCode > > http://cr.openjdk.java.net/~coffeys/webrev.7091388.jdk8/ The approach looks okay to me. I guess there isn't any need for these methods to be protected and it's just for consistency with the existing code. -Alan. From Vasanth.Venkatachalam at amd.com Thu Nov 10 19:20:02 2011 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 10 Nov 2011 13:20:02 -0600 Subject: configuring Java to use SunPKCS11 on SLES Message-ID: I'm trying to configure the Java runtime to use SunPKCS11 as the default security provider on a SLES11 64-bit box. I was following the documentation at: http://download.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html The above doc says that the SunPKCS11 provider requires an implementation of PKCS11 v2.0 or later to be installed in the form of a shared library. Does anyone know where I can find the shared library I would have to install for SLES 11 64-bit? I found an opensc-pkcs11.so file under /usr/lib64/pkcs11 but I'm not sure whether that's the one I should use. I installed it following the directions in the above doc (editing the java.security file and specifying the path to the .so in a config file), but when I run a sample Java program that prints the list of services of this provider, this list comes up empty. -- Vasanth Venkatachalam AMD Runtimes (512)602-6177 From Alan.Bateman at oracle.com Thu Nov 10 21:21:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Nov 2011 21:21:11 +0000 Subject: code review request : 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile In-Reply-To: <4EB3E3D9.4050807@oracle.com> References: <4EAAF0C4.5070806@oracle.com> <4EAD7C42.1000103@oracle.com> <4EAFC042.5080907@oracle.com> <4EB0E4C0.1040804@oracle.com> <4EB3E3D9.4050807@oracle.com> Message-ID: <4EBC4047.40901@oracle.com> On 04/11/2011 13:08, Se?n Coffey wrote: > ok, > > so updated webrev at : > http://cr.openjdk.java.net/~coffeys/webrev.7105952.2/ > > some minor modifications : > > * "closed" variable made private > * hg mv instead of rm/add for testcase > * testcase padded up some more. > * comments changed to block style format in FileDescriptor. > * some extra comments added to FileDescriptor to help read code > > I'll leave the javadoc changes for another bugID/CCC request. I agree that clarification to the javadoc should be separate. Overall I'm happy with the approach. As I mentioned in one of the mails, it would be great to avoid duplicating code between the two FileDescriptor implementations but I appreciate you are focused on this specific issue at this time. On the suppressed exceptions then it's as before: if the release's close method fails then it will have at most one suppressed exception which may, in turn, have zero or more suppressed exceptions. This isn't a scenario that the tests exercise (and probably can't test either). This may be something we might want to clean-up sometime. -Alan From sean.coffey at oracle.com Fri Nov 11 10:09:07 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 11 Nov 2011 10:09:07 +0000 Subject: hg: jdk8/tl/jdk: 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Message-ID: <20111111100937.879D647312@hg.openjdk.java.net> Changeset: 9dd994f319ee Author: coffeys Date: 2011-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9dd994f319ee 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/solaris/classes/java/io/FileDescriptor.java ! src/windows/classes/java/io/FileDescriptor.java - test/java/io/FileDescriptor/FileChannelFDTest.java + test/java/io/FileDescriptor/Sharing.java - test/java/io/etc/FileDescriptorSharing.java From sean.coffey at oracle.com Fri Nov 11 10:16:25 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 11 Nov 2011 10:16:25 +0000 Subject: hg: jdk8/tl/corba: 7091388: Regular unexplained npe's from corba libs after system has been running for days Message-ID: <20111111101628.4F27947313@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/44c269731425 7091388: Regular unexplained npe's from corba libs after system has been running for days Reviewed-by: alanb ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java From gary.adams at oracle.com Fri Nov 11 16:56:48 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 11 Nov 2011 11:56:48 -0500 Subject: CR 6860309 - solaris timing issue on thread startup Message-ID: <4EBD53D0.6050808@oracle.com> CR 6860309 - TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java A timing problem is reported for slow solaris systems for this test to start up a process and systematically torture the underlying threads processing data from the running process. On my fast solaris machine I can not reproduce the error, but it is reasonable to assume that on a slower machine there could be scheduling issues that could delay the thread startup past the designated 100 millisecond delay in the main thread. This webrev suggests gating the process destruction until both worker threads are alive. http://cr.openjdk.java.net/~gadams/6860309/ From darryl.mocek at oracle.com Fri Nov 11 18:27:29 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 11 Nov 2011 10:27:29 -0800 Subject: Fwd: RE: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: References: Message-ID: <4EBD6911.2090407@oracle.com> Hi Jason. I'm the engineer implementing this RFE. Mike is committing the fix for me as I don't yet have commit rights to the repository. Please see my comments inline. Darryl -------- Original Message -------- Subject: RE: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) Date: Fri, 4 Nov 2011 12:52:54 -0500 From: Jason Mehrens To: , CC: core-libs-dev at openjdk.java.net Mike, These 'simple' classes are really hard to get right. Here is my review of the change: 1. Why not extend EmptySet? You wouldn't have to implement so many methods. Good point. 2. The comparator method is using raw types. The SortedSet.comparator() method spec allows returning of null. 3. The readResolve method comment is just wrong. Create a default access static final reference named EMPTY_SORTED_SET inside of the EmptySortedSet and use that in readResolve and in Collections.emptySortedSet. Yes. This comment was left over from when the EMPTY_SORTED_SET field was there. I missed this, thanks. 4. Only the IAE if statement is need for your range checks. NPE and CCE will occur in that if statement by default. CCE lacks a descriptive message the you get if you used Class.cast or just an implicit cast. True. I'm trying to be clear in the code that the parameters are checked for these things. Is this an optimization/style issue? What is the preference here? 5. What if I want to create an empty set sorted set with supplied comparator? Extend EmptySortedSet and override the comparator method. I believe most uses of EmptySortedSet will not want to supply their own Comparator. I can support a suppliable Comparator if there's enough interest. 6. Why not implement an EmptyNavigableSet instead since the bug was entered before 1.6? Is NavigableSet preferrable to SortedSet? There is currently no request for EmptyNavigableSet, just EmptySortedSet. Did I make the case for a follow up review? :) Regards, Jason > Subject: Re: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) > From:mike.duigou at oracle.com > Date: Fri, 4 Nov 2011 09:29:09 -0700 > To:David.Holmes at oracle.com > CC:core-libs-dev at openjdk.java.net > > > On Nov 3 2011, at 17:40 , David Holmes wrote: > > > Mike, > > > > I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. > > I missed your question about the range on an empty set. My comments below. > > Removing EMPTY_SORTED_SET was the only other comment to my knowledge. Darryl adapted the patch and EMPTY_SORTED_SET was not part of the commit. Since the change was removal of a newly proposed field an additional review cycle wasn't thought to be necessary. Perhaps incorrectly? From darryl.mocek at oracle.com Fri Nov 11 19:37:14 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 11 Nov 2011 11:37:14 -0800 Subject: Code Review Request for 6578042 In-Reply-To: <4EB6653A.7020405@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> Message-ID: <4EBD796A.3040400@oracle.com> The reason I used the Object's toString method is that there may indeed be an object which is not a String which is stored as a value (this was the reason for the bug report). In this case, the remove method will in fact remove the property. Returning null if the value is not a String gives the impression that there was no property with that key when the property may have been there and may in fact have been removed. Using toString gives a best effort to notify the caller that the property was removed, even if the value is not a String. This to me is a bit different from getProperty. Returning null from getProperty gives the impression there is no property with the specified key, which may be false if the value is not a String, but you could argue that a non-String value is not a valid property anyway and should not be returned from getProperty. However, clearProperty will actually remove an invalid property. I will add to the Javadoc comment for the getProperty(String key) method that null may be returned if the property value is not a String. I would prefer it if Properties didn't allow non-String keys and values at all since they're supposed to be Strings (by API implication) and that Properties not extend Hashtable or extends Hashtable, but I digress. Darryl On Sun 06 Nov 2011 02:45:14 AM PST, Alan Bateman wrote: > > On 02/11/2011 19:59, David Holmes wrote: >> >> >> I'm not seeing a distinction in those two statements. Both expect to >> return the property value for a given key; both assume a valid value >> is a String. clearProperty throws ClassCastException if the >> assumption doesn't hold; getProperty instead returns null. > > The distinction is "value" vs. "string value", where the latter is > interpreted by Darryl's patch to be the String representation. While > that avoids the CCE, it is clearly inconsistent with > System.getProperty that I see is also specified to return the "string > value". So I think we have to dismiss this approach. I think this > leaves two options: > > 1. Document existing behavior, meaning @throws CCE (several of > Properties methods already have this). > > 2. Change the method so that it is consistent with getProperty and so > returns null if the property value is not a String. > > While option 2 is clearly a change then I think it's worth exploring > to understand the impact. Properties has always had a note in its > javadoc to warn users that it inherits from Hashtable and it has a > note to "strongly discourage" inserting entries that have a key or > value that is not a String. My guess (and this is purely a guess) is > that System.clearProperty is not used very often and so the likelihood > of someone abusing the system properties and using clearProperty is > probably low. I see the bug on bugs.sun.com doesn't have any votes or > comments which suggests that this one doesn't have an angry mob either. > > Darryl - since you have decided to tackle this one then I would > suggest looking into this further and coming back with a > recommendation. I would also suggest that as part of the patch that > the javadoc for System.getProperty and Properties.getProperty be > clarified so that it's clear that they return null when the properties > have been compromised. > > -Alan. From david.holmes at oracle.com Sat Nov 12 03:44:50 2011 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Nov 2011 13:44:50 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EBD53D0.6050808@oracle.com> References: <4EBD53D0.6050808@oracle.com> Message-ID: <4EBDEBB2.4090007@oracle.com> Hi Gary, On 12/11/2011 2:56 AM, Gary Adams wrote: > CR 6860309 - TEST_BUG: Insufficient sleep time in > java/lang/Runtime/exec/StreamsSurviveDestroy.java > > A timing problem is reported for slow solaris systems for this > test to start up a process and systematically torture the underlying > threads processing data from the running process. > > On my fast solaris machine I can not reproduce the error, > but it is reasonable to assume that on a slower machine there > could be scheduling issues that could delay the thread startup > past the designated 100 millisecond delay in the main thread. > > This webrev suggests gating the process destruction until both > worker threads are alive. > > http://cr.openjdk.java.net/~gadams/6860309/ This doesn't achieve anything I'm afraid. isAlive() will return true once start() has been invoked on the thread (it doesn't depend on the new thread getting scheduled to run), hence there will only be a single call to sleep - no different from today. If the issue is that c1 and c2 have not performed some action necessary before the process interaction then that action needs to be synchronized with explicitly. David ----- From Alan.Bateman at oracle.com Sat Nov 12 11:58:43 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Nov 2011 11:58:43 +0000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EBD53D0.6050808@oracle.com> References: <4EBD53D0.6050808@oracle.com> Message-ID: <4EBE5F73.706@oracle.com> On 11/11/2011 16:56, Gary Adams wrote: > CR 6860309 - TEST_BUG: Insufficient sleep time in > java/lang/Runtime/exec/StreamsSurviveDestroy.java > > A timing problem is reported for slow solaris systems for this > test to start up a process and systematically torture the underlying > threads processing data from the running process. > > On my fast solaris machine I can not reproduce the error, > but it is reasonable to assume that on a slower machine there > could be scheduling issues that could delay the thread startup > past the designated 100 millisecond delay in the main thread. > > This webrev suggests gating the process destruction until both > worker threads are alive. > > http://cr.openjdk.java.net/~gadams/6860309/ > > -Xcomp on a slow machine, always fun when testing the untestable. I agree with David but I don't think there is perfect solution. I would suggest using a CountDownLatch or other synchronization so that the main thread waits until the Copier thread is just about to do the read. Then do a sleep in the main thread before invoking the destroy method. I suspect that is the best that you can do as can't be guaranteed that the Copier thread is blocked in the underlying read. -Alan. From gary.adams at oracle.com Sat Nov 12 12:11:10 2011 From: gary.adams at oracle.com (Gary Adams) Date: Sat, 12 Nov 2011 07:11:10 -0500 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EBE5F73.706@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> Message-ID: <4EBE625E.80308@oracle.com> On 11/12/11 6:58 AM, Alan Bateman wrote: > On 11/11/2011 16:56, Gary Adams wrote: >> CR 6860309 - TEST_BUG: Insufficient sleep time in >> java/lang/Runtime/exec/StreamsSurviveDestroy.java >> >> A timing problem is reported for slow solaris systems for this >> test to start up a process and systematically torture the underlying >> threads processing data from the running process. >> >> On my fast solaris machine I can not reproduce the error, >> but it is reasonable to assume that on a slower machine there >> could be scheduling issues that could delay the thread startup >> past the designated 100 millisecond delay in the main thread. >> >> This webrev suggests gating the process destruction until both >> worker threads are alive. >> >> http://cr.openjdk.java.net/~gadams/6860309/ >> >> > -Xcomp on a slow machine, always fun when testing the untestable. > > I agree with David but I don't think there is perfect solution. I > would suggest using a CountDownLatch or other synchronization so that > the main thread waits until the Copier thread is just about to do the > read. Then do a sleep in the main thread before invoking the destroy > method. I suspect that is the best that you can do as can't be > guaranteed that the Copier thread is blocked in the underlying read. > > -Alan. I'll give it a try on Monday. Ideally, I could get a reproducible failure before trying to fix the problem. Unfortunately, the only slow machines I have on hand are linux/arm, which might have different issues from the solaris/sparc originally reported. From Alan.Bateman at oracle.com Sat Nov 12 12:14:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 12 Nov 2011 12:14:38 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EBD796A.3040400@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> Message-ID: <4EBE632E.8090901@oracle.com> On 11/11/2011 19:37, Darryl Mocek wrote: > Returning null if the value is not a String gives the impression that > there was no property with that key when the property may have been > there and may in fact have been removed. That's a fair point and probably enough to conclude that this approach should be dismissed. The toString approach is inconsistent so I think this brings us back to the original suggestion which is to specify that CCE is thrown (as it always has) but without side effects (meaning it doesn't remove the property). I think this is the best we can do with this broken API. : > > I would prefer it if Properties didn't allow non-String keys and > values at all since they're supposed to be Strings (by API > implication) and that Properties not extend Hashtable or extends > Hashtable, but I digress. Properties goes back to JDK1.0 and has a warning in its javadoc for many years to discourage inserting keys or values that are not Strings. I'm not sure whether we can do much about it now without risking compatibility issues. -Alan. From jason_mehrens at hotmail.com Sun Nov 13 18:30:16 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sun, 13 Nov 2011 12:30:16 -0600 Subject: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) In-Reply-To: <4EBD6911.2090407@oracle.com> References: , <4EBD6911.2090407@oracle.com> Message-ID: Darryl, >> 2. The comparator method is using raw types. >The SortedSet.comparator() method spec allows returning of null. Right. But, the return type of the implementation is a raw comparator not Comparator defined by the interface. >> 4. Only the IAE if statement is need for your range checks. NPE and CCE will occur in that if statement by default. CCE lacks a descriptive message the you get if you used Class.cast or just an implicit cast. >True. I'm trying to be clear in the code that the parameters are checked for these things. Is this an optimization/style issue? What is the preference here? My thought is that implicit code is more compact and produces a more descriptive error message on CCE. >> 5. What if I want to create an empty set sorted set with supplied comparator? >Extend EmptySortedSet and override the comparator method. I believe most uses of EmptySortedSet will not want to supply their own Comparator. I can support a suppliable Comparator if there's enough interest. Extending is not an option because EmptySortedSet is private class, as it should be. Since the EmptySortedSet is serializable, adding support later on gets ugly. >>6. Why not implement an EmptyNavigableSet instead since the bug was entered before 1.6? >Is NavigableSet preferrable to SortedSet? There is currently no request for EmptyNavigableSet, just EmptySortedSet. My understanding is that NavigableSet is preferred to SortedSet. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6415641 Jason > Subject: Re: Code Review Request for 4533691 (add Collections.EMPTY_SORTED_SET) > From: mike.duigou at oracle.com > Date: Fri, 4 Nov 2011 09:29:09 -0700 > To: David.Holmes at oracle.com > CC: core-libs-dev at openjdk.java.net > > > On Nov 3 2011, at 17:40 , David Holmes wrote: > > > Mike, > > > > I see that you have pushed a version of this change and that I was listed as a reviewer. However I never saw an updated webrev and there was no response to my query below. In fact I never saw any response to any of the reviewers comments on this. > > I missed your question about the range on an empty set. My comments below. > > Removing EMPTY_SORTED_SET was the only other comment to my knowledge. Darryl adapted the patch and EMPTY_SORTED_SET was not part of the commit. Since the change was removal of a newly proposed field an additional review cycle wasn't thought to be necessary. Perhaps incorrectly? From david.holmes at oracle.com Mon Nov 14 00:28:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Nov 2011 10:28:18 +1000 Subject: Code Review Request for 6578042 In-Reply-To: <4EBE632E.8090901@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> Message-ID: <4EC060A2.3050109@oracle.com> On 12/11/2011 10:14 PM, Alan Bateman wrote: > On 11/11/2011 19:37, Darryl Mocek wrote: >> Returning null if the value is not a String gives the impression that >> there was no property with that key when the property may have been >> there and may in fact have been removed. > That's a fair point and probably enough to conclude that this approach > should be dismissed. > > The toString approach is inconsistent so I think this brings us back to > the original suggestion which is to specify that CCE is thrown (as it > always has) but without side effects (meaning it doesn't remove the > property). I think this is the best we can do with this broken API. I tend to agree. If the value is not a string then leave it alone and throw CCE. David ----- > : >> >> I would prefer it if Properties didn't allow non-String keys and >> values at all since they're supposed to be Strings (by API >> implication) and that Properties not extend Hashtable or extends >> Hashtable, but I digress. > Properties goes back to JDK1.0 and has a warning in its javadoc for many > years to discourage inserting keys or values that are not Strings. I'm > not sure whether we can do much about it now without risking > compatibility issues. > > -Alan. From david.holmes at oracle.com Mon Nov 14 00:42:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Nov 2011 10:42:16 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EBE5F73.706@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> Message-ID: <4EC063E8.6050703@oracle.com> Alan, On 12/11/2011 9:58 PM, Alan Bateman wrote: > On 11/11/2011 16:56, Gary Adams wrote: >> CR 6860309 - TEST_BUG: Insufficient sleep time in >> java/lang/Runtime/exec/StreamsSurviveDestroy.java >> >> A timing problem is reported for slow solaris systems for this >> test to start up a process and systematically torture the underlying >> threads processing data from the running process. >> >> On my fast solaris machine I can not reproduce the error, >> but it is reasonable to assume that on a slower machine there >> could be scheduling issues that could delay the thread startup >> past the designated 100 millisecond delay in the main thread. >> >> This webrev suggests gating the process destruction until both >> worker threads are alive. >> >> http://cr.openjdk.java.net/~gadams/6860309/ >> >> > -Xcomp on a slow machine, always fun when testing the untestable. > > I agree with David but I don't think there is perfect solution. I would > suggest using a CountDownLatch or other synchronization so that the main > thread waits until the Copier thread is just about to do the read. Then > do a sleep in the main thread before invoking the destroy method. I > suspect that is the best that you can do as can't be guaranteed that the > Copier thread is blocked in the underlying read. Will the exec'd process block until the copier threads read from its output streams? If not then the copier threads (well stdin anyway) could read their input and have terminated before the main thread even reaches the original sleep() call. I don't think this test can be written correctly as-is. Even using a CountDownLatch won't help because you have to sync with two copier threads, so the first could be finished before the second signals the latch. I would think we would need to exec our own process (a Java one of course) that assists with the synchronization issue - ie by not terminating until it receives an input token. At least that way we know the copier threads can not proceed passed the read() calls, even if we can't be 100% certain they are in the read at the time the process is destroyed. Gary: while fixing timing bugs is a worthwhile goal in terms of test stability etc it is rarely if ever "low hanging fruit" as you have found. David > -Alan. From Alan.Bateman at oracle.com Mon Nov 14 08:05:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Nov 2011 08:05:26 +0000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC063E8.6050703@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EC063E8.6050703@oracle.com> Message-ID: <4EC0CBC6.5060708@oracle.com> On 14/11/2011 00:42, David Holmes wrote: > > Will the exec'd process block until the copier threads read from its > output streams? If not then the copier threads (well stdin anyway) > could read their input and have terminated before the main thread even > reaches the original sleep() call. > > I don't think this test can be written correctly as-is. Even using a > CountDownLatch won't help because you have to sync with two copier > threads, so the first could be finished before the second signals the > latch. > > I would think we would need to exec our own process (a Java one of > course) that assists with the synchronization issue - ie by not > terminating until it receives an input token. At least that way we > know the copier threads can not proceed passed the read() calls, even > if we can't be 100% certain they are in the read at the time the > process is destroyed. The test runs cat without any arguments so the Copier threads will block when they read from the stream. If we can get the main thread to wait until the Copier threads are just about to do the read, sleep for a bit, then the threads should be blocked in the read when we destroy the process. It's not ideal but I don't think there is any other way to test this. -Alan. From luchsh at linux.vnet.ibm.com Mon Nov 14 08:40:01 2011 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 14 Nov 2011 16:40:01 +0800 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBB4062.8050403@intricatesoftware.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> Message-ID: <4EC0D3E1.6080807@linux.vnet.ibm.com> Hi Kurt, On 11/10/2011 11:09 AM, Kurt Miller wrote: > On 11/09/11 03:01, Jonathan Lu wrote: >> On 11/04/2011 01:26 PM, David Holmes wrote: >>> On 4/11/2011 2:53 PM, David Holmes wrote: >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>>> 10.03. The difference still exists. >>>>> >>>>> Solaris 10: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:04:45 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 13:04:53 JST 2011 >>>>> >>>>> Ubuntu 10.04: >>>>> $ unset TZ >>>>> $ date >>>>> Fri Nov 4 13:05:50 JST 2011 >>>>> $ TZ="" date >>>>> Fri Nov 4 04:05:55 UTC 2011 >>>>> >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>>> still looks up the system default. >>>> I have to take back my comment regarding this not seeming to be platform >>>> specific code - it is highly platform specific! It seems that on Linux >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>>> is an attempt to keep Java's use of TZ consistent with how other apps >>>> handle it on that platform. (environ(5) gives a little insight on >>>> Solaris as to how TZ is used.) >>>> >>>> So the key thing here is to not disturb the existing behaviour on either >>>> linux or Solaris - which suggests the original patch. That said I'm not >>>> convinced - given this is so platform specific - that simply treating >>>> non-linux the same as Solaris is a reasonable thing to do. I think it >>>> would be useful to see what the BSD/OSX port(s) had to do with this code >>>> - if anything. >>> To answer my own queries BSD/OSX does >>> >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >>> 512 if (tz == NULL) { >>> 513 #else >>> 514 #ifdef __solaris__ >>> 515 if (tz == NULL || *tz == '\0') { >>> 516 #endif >>> 517 #endif >>> >>> so the suggested patch would at least not interfere. >>> >>> Anyway this needs input from other core-libs folk. I didn't intend to >>> get quite so heavily involved. ;-) >>> >>> David >>> ----- >>> >>> >>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>>> Hi Masayoshi, >>>>>> >>>>>> I did find some references about date-time related functions / TZ >>>>>> variables on Linux but got only a few about Solaris, so could not see >>>>>> any differences between those two platforms about the changes >>>>>> described in my patch. Have you got any links or references about >>>>>> these differences? I'm interested in it and may update the patch again >>>>>> after reading them. >>>>>> >>>>>> Thanks a lot! >>>>>> - Jonathan >>>>>> >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> IIRC, the difference came from some behavioral difference between the >>>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>>> written looooong ago. The difference may no longer exist. >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>>> Hi core-libs-dev, >>>>>>>>>>> >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>>> line >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>>> currently >>>>>>>>>>> working on, such as AIX. >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>>> the >>>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>>> 'patch.diff'. I >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>>> about >>>>>>>>>>> this modification? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> - Jonathan Lu >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>>> mail >>>>>>>>>> content directly. >>>>>>>>>> >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>>> 19:06:53 >>>>>>>>>> 2011 -0700 >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>>> 13:43:47 >>>>>>>>>> 2011 +0800 >>>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>>> #ifdef __linux__ >>>>>>>>>> if (tz == NULL) { >>>>>>>>>> #else >>>>>>>>>> -#ifdef __solaris__ >>>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>>> #endif >>>>>>>>>> -#endif >>>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>>> freetz = tz; >>>>>>>>>> } >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>>> following would be platform neutral: >>>>>>>>> >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>>> be retrieved from that environment variable. >>>>>>>> So I changed the patch to this, >>>>>>>> >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>>> 2011 -0700 >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>>> 2011 +0800 >>>>>>>> @@ -623,13 +623,7 @@ >>>>>>>> >>>>>>>> tz = getenv("TZ"); >>>>>>>> >>>>>>>> -#ifdef __linux__ >>>>>>>> - if (tz == NULL) { >>>>>>>> -#else >>>>>>>> -#ifdef __solaris__ >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> -#endif >>>>>>>> -#endif >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>> Regards >>>>>>>> >>>>>>>> - Jonathan >>>>>>>> >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here >> has some ideas about this issue. > Hi Jonathan, > > The above email is a bit hard to follow due to the mixture of top and > bottom replies. > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > which confirms the need for platform ifdef's in this code. > > Seems like you need to make the following change: > > -#ifdef __solaris__ > +#if defined(__solaris__) || defined(__AIX__) > > or something similar to maintain compatibility. > > In general the approach taken for adding BSD support was to never > assume you can change other supported code paths. If your architecture > follows an existing code path behavior add it like I did above. > Otherwise just create a #ifdef myarch section for it. > But for this case, I think it is a good idea to leave a default code path here. Since in src/solaris/native/java/util/TimeZone_md.c starting from line 624, the return value of getenv("TZ"); has to be tested afterward on any platforms. So to improve portability for OpenJDK, how about leaving Solaris style checking as the default approach? > Unifying or changing another architecture's code path requires access > to the arch, research and confirmation that the change is ok. Typically > this may be done by writing independent test programs and running them > on each arch. > > Regards, > -Kurt > > > From xuelei.fan at oracle.com Mon Nov 14 09:22:25 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 Nov 2011 09:22:25 +0000 Subject: hg: jdk8/tl/jdk: 7111548: unexpected debug log message Message-ID: <20111114092249.A7D3747352@hg.openjdk.java.net> Changeset: 5c7c83a6ee24 Author: xuelei Date: 2011-11-14 01:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c7c83a6ee24 7111548: unexpected debug log message Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From chris.hegarty at oracle.com Mon Nov 14 11:06:19 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 14 Nov 2011 11:06:19 +0000 Subject: hg: jdk8/tl/jdk: 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Message-ID: <20111114110642.BEABE47356@hg.openjdk.java.net> Changeset: 68fc55d12ae6 Author: chegar Date: 2011-11-14 10:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68fc55d12ae6 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/classes/java/net/PlainSocketImpl.java From neil.richards at ngmr.net Mon Nov 14 13:19:04 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 14 Nov 2011 13:19:04 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EC060A2.3050109@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC060A2.3050109@oracle.com> Message-ID: <1321276744.29601.45.camel@chalkhill> On Mon, 2011-11-14 at 10:28 +1000, David Holmes wrote: > On 12/11/2011 10:14 PM, Alan Bateman wrote: > > On 11/11/2011 19:37, Darryl Mocek wrote: > >> Returning null if the value is not a String gives the impression that > >> there was no property with that key when the property may have been > >> there and may in fact have been removed. > > That's a fair point and probably enough to conclude that this approach > > should be dismissed. > > > > The toString approach is inconsistent so I think this brings us back to > > the original suggestion which is to specify that CCE is thrown (as it > > always has) but without side effects (meaning it doesn't remove the > > property). I think this is the best we can do with this broken API. > > I tend to agree. If the value is not a string then leave it alone and > throw CCE. Of course, there are certain situations where the Java documentation guides you to specify property values which are not String objects. One that springs to my mind is the setting of "java.naming.corba.orb" to point to the ORB instance to be used by the JNDI/COS Naming Service Provider [1]. (For those using this provider, this setting tends to be important in limiting the resources it consumes). So I'm not sure it's correct to assume that it is an error for Property settings to have non-String values. Regards, Neil [1] http://download.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-cos.html#PROP -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Mon Nov 14 13:45:41 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Nov 2011 13:45:41 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <1321276744.29601.45.camel@chalkhill> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC060A2.3050109@oracle.com> <1321276744.29601.45.camel@chalkhill> Message-ID: <4EC11B85.3090506@oracle.com> On 14/11/2011 13:19, Neil Richards wrote: > : > > Of course, there are certain situations where the Java documentation > guides you to specify property values which are not String objects. > > One that springs to my mind is the setting of "java.naming.corba.orb" to > point to the ORB instance to be used by the JNDI/COS Naming Service > Provider [1]. > > (For those using this provider, this setting tends to be important in > limiting the resources it consumes). > > So I'm not sure it's correct to assume that it is an error for Property > settings to have non-String values. > Neil - I think this is a property that is specified in the JNDI environment (so Hashtable rather than Properties). The only method that is impacted by the discussion here is System.clearProperty which has always thrown CastClassException if invoked to remove a property that doesn't have a String value. I think we're concluding that the only thing we do can is fix it so that it doesn't remove the property when it fails (and clarify the javadoc accordingly). -Alan. From gary.adams at oracle.com Mon Nov 14 16:09:51 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 14 Nov 2011 11:09:51 -0500 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EBE625E.80308@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> Message-ID: <4EC13D4F.8010108@oracle.com> I've updated the webrev for CR#6860309 using a CountDownLatch. The main thread will wait til both worker threads are ready to block on the read() before the process is destroyed. http://cr.openjdk.java.net/~gadams/6860309/ Tested with -Xcomp, but still may need a older slow solaris/sparc machine to confirm the fix works for the original bug submitter. From kumar.x.srinivasan at oracle.com Mon Nov 14 16:38:16 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 14 Nov 2011 16:38:16 +0000 Subject: hg: jdk8/tl/langtools: 7110974: (javac) add coding conventions and style checkers for langtools Message-ID: <20111114163820.B61A847358@hg.openjdk.java.net> Changeset: c1238fcc9515 Author: ksrini Date: 2011-11-14 08:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c1238fcc9515 7110974: (javac) add coding conventions and style checkers for langtools Reviewed-by: jjg ! make/build.properties ! make/build.xml + make/conf/checkstyle-emacs.xsl + make/conf/checkstyle-langtools.xml From forax at univ-mlv.fr Mon Nov 14 17:36:57 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Nov 2011 18:36:57 +0100 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC13D4F.8010108@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> Message-ID: <4EC151B9.90303@univ-mlv.fr> On 11/14/2011 05:09 PM, Gary Adams wrote: > I've updated the webrev for CR#6860309 using a CountDownLatch. > The main thread will wait til both worker threads are ready to > block on the read() before the process is destroyed. > > http://cr.openjdk.java.net/~gadams/6860309/ > > Tested with -Xcomp, but still may need a older slow solaris/sparc > machine to confirm the fix works for the original bug > submitter. > Hi Gary, I think it's better if a Copier takes the CountDownLatch as parameter of the constructor instead of being declared static. R?mi From gary.adams at oracle.com Mon Nov 14 20:32:20 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 14 Nov 2011 15:32:20 -0500 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC13D4F.8010108@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> Message-ID: <4EC17AD4.80800@oracle.com> Updated to move static latch to Copier constructor argument. On 11/14/11 11:09 AM, Gary Adams wrote: > I've updated the webrev for CR#6860309 using a CountDownLatch. > The main thread will wait til both worker threads are ready to > block on the read() before the process is destroyed. > > http://cr.openjdk.java.net/~gadams/6860309/ > > Tested with -Xcomp, but still may need a older slow solaris/sparc > machine to confirm the fix works for the original bug > submitter. > From mandy.chung at oracle.com Mon Nov 14 20:53:10 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Nov 2011 12:53:10 -0800 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBBE286.10109@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> Message-ID: <4EC17FB6.8010507@oracle.com> On 11/10/11 06:41, Gary Adams wrote: > On 11/ 8/11 11:13 PM, Mandy Chung wrote: >> >> >> Thanks for picking up this bug and fixing this intermittent issue. >> PlatformLoggingMXBeanTest.java in the same directory has the same >> issue. It'd be good to fix that with the same CR. These tests were >> copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't >> looked in details but I wonder why the test/java/util/logging tests >> don't have this intermittent issue and I suspect it holds a strong >> reference. > > I attempted to break PlatformLoggingMXBeanTest.java with a generous > application of > GC calls, but I could not get it to fail in the same manner as the > other test. It may be > failing due to a different condition. > It's a timing issue when Logger.getLogger and setLogLevel method are called. If you move these 2 lines: Logger logger1 = Logger.getLogger( LOGGER_NAME_1 ); Logger logger2 = Logger.getLogger( LOGGER_NAME_2 ); to the PlatformLoggerMXBeanTest constructor (this is about the same place to when LoggingMXBeanTest calls Logger.getLogger), I am able to reproduce the problem. It's harder to reproduce the problem when the timing window between Logger.getLogger that creates a reference the logger on stack and setLogLevel method call is probably too small that GC hardly occurs in the systems I tried. Give it a try to see if this helps. I took your patch and generate the webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7067691/webrev.00/ line 46: about the name, how about simply renaming it to "test" ? line 230-232: I wonder if the bracket is intentional? Mandy From kumar.x.srinivasan at oracle.com Mon Nov 14 23:36:33 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 14 Nov 2011 23:36:33 +0000 Subject: hg: jdk8/tl/langtools: 7106166: (javac) re-factor EndPos parser Message-ID: <20111114233635.3AB444735E@hg.openjdk.java.net> Changeset: 7375d4979bd3 Author: ksrini Date: 2011-11-14 15:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7375d4979bd3 7106166: (javac) re-factor EndPos parser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/TreePosTest.java From david.holmes at oracle.com Tue Nov 15 00:48:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 10:48:16 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC0CBC6.5060708@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EC063E8.6050703@oracle.com> <4EC0CBC6.5060708@oracle.com> Message-ID: <4EC1B6D0.4000804@oracle.com> On 14/11/2011 6:05 PM, Alan Bateman wrote: > The test runs cat without any arguments so the Copier threads will block > when they read from the stream. Thank's Alan that critical point had escaped my notice. David If we can get the main thread to wait > until the Copier threads are just about to do the read, sleep for a bit, > then the threads should be blocked in the read when we destroy the > process. It's not ideal but I don't think there is any other way to test > this. > > -Alan. From david.holmes at oracle.com Tue Nov 15 00:56:53 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 10:56:53 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC13D4F.8010108@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> Message-ID: <4EC1B8D5.2020104@oracle.com> On 15/11/2011 2:09 AM, Gary Adams wrote: > I've updated the webrev for CR#6860309 using a CountDownLatch. > The main thread will wait til both worker threads are ready to > block on the read() before the process is destroyed. > > http://cr.openjdk.java.net/~gadams/6860309/ 25 * @bug 4820217 6860309 As per other emails and still waiting from confirmation from Alan. I don't think the @bug should be updated for any of these test fixes. 47 boolean ae, boolean wi,CountDownLatch l) style: Missing space after comma 110 latch.await(); 111 Thread.sleep(100); The test already lacks comments, I suggest adding: 110 latch.await(); // wait till both Copiers about to read 111 Thread.sleep(100); // Give both Copiers a chance to start read Ditto for the other tests > Tested with -Xcomp, but still may need a older slow solaris/sparc > machine to confirm the fix works for the original bug > submitter. Difficult to test. Trying using a slower T1000 and binding the JVM to only a single core. The fix improves the chances of success but is still not fool-proof by any means. Thanks for your perseverance. David From david.holmes at oracle.com Tue Nov 15 01:23:25 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Nov 2011 11:23:25 +1000 Subject: Code Review Request for 6578042 In-Reply-To: <1321276744.29601.45.camel@chalkhill> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC060A2.3050109@oracle.com> <1321276744.29601.45.camel@chalkhill> Message-ID: <4EC1BF0D.5060006@oracle.com> On 14/11/2011 11:19 PM, Neil Richards wrote: > On Mon, 2011-11-14 at 10:28 +1000, David Holmes wrote: >> On 12/11/2011 10:14 PM, Alan Bateman wrote: >>> On 11/11/2011 19:37, Darryl Mocek wrote: >>>> Returning null if the value is not a String gives the impression that >>>> there was no property with that key when the property may have been >>>> there and may in fact have been removed. >>> That's a fair point and probably enough to conclude that this approach >>> should be dismissed. >>> >>> The toString approach is inconsistent so I think this brings us back to >>> the original suggestion which is to specify that CCE is thrown (as it >>> always has) but without side effects (meaning it doesn't remove the >>> property). I think this is the best we can do with this broken API. >> >> I tend to agree. If the value is not a string then leave it alone and >> throw CCE. > > Of course, there are certain situations where the Java documentation > guides you to specify property values which are not String objects. > > One that springs to my mind is the setting of "java.naming.corba.orb" to > point to the ORB instance to be used by the JNDI/COS Naming Service > Provider [1]. But these are not System property values being described. David ----- > (For those using this provider, this setting tends to be important in > limiting the resources it consumes). > > So I'm not sure it's correct to assume that it is an error for Property > settings to have non-String values. > > Regards, Neil > > [1] http://download.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-cos.html#PROP > From neil.richards at ngmr.net Tue Nov 15 02:43:33 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 15 Nov 2011 02:43:33 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EC11B85.3090506@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC060A2.3050109@oracle.com> <1321276744.29601.45.camel@chalkhill> <4EC11B85.3090506@oracle.com> Message-ID: <1321325013.29601.169.camel@chalkhill> On Mon, 2011-11-14 at 13:45 +0000, Alan Bateman wrote: > On 14/11/2011 13:19, Neil Richards wrote: > > : > > > > Of course, there are certain situations where the Java documentation > > guides you to specify property values which are not String objects. > > > > One that springs to my mind is the setting of "java.naming.corba.orb" to > > point to the ORB instance to be used by the JNDI/COS Naming Service > > Provider [1]. > > > > (For those using this provider, this setting tends to be important in > > limiting the resources it consumes). > > > > So I'm not sure it's correct to assume that it is an error for Property > > settings to have non-String values. > > > Neil - I think this is a property that is specified in the JNDI > environment (so Hashtable rather than Properties). The only method > that is impacted by the discussion here is System.clearProperty which > has always thrown CastClassException if invoked to remove a property > that doesn't have a String value. I think we're concluding that the only > thing we do can is fix it so that it doesn't remove the property when it > fails (and clarify the javadoc accordingly). > > -Alan. Hi Alan, Ah yes, I see - having looked over the API for System properties again, and that for InitialContext, I agree with what you say. (My recollection was that one could set this JNDI environment via the System properties, but I now see it would be unreasonably tortuous to try to set things up in this way, given the way the System properties API is defined.) Hmm. Post in haste, recant at leisure. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From lvjing at linux.vnet.ibm.com Tue Nov 15 08:09:57 2011 From: lvjing at linux.vnet.ibm.com (Jing Lv) Date: Tue, 15 Nov 2011 16:09:57 +0800 Subject: A method with return type size_t returns negative value In-Reply-To: <4EBA4060.6030706@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> Message-ID: <4EC21E55.3030106@linux.vnet.ibm.com> Hello, I search the E:\workspace\openjdk\jdk\src\windows\native but find nothing similar (please tell me if I miss something), so I suggest we have a quick fix for now, like: --- E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.h~ 2011-11-15 15:53:21.000000000 +0800 +++ E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.h 2011-11-15 15:56:27.000000000 +0800 @@ -36,14 +36,14 @@ WCHAR* currentDir(int di); int currentDirLength(const WCHAR* path, int pathlen); void fileOpen(JNIEnv *env, jobject this, jstring path, jfieldID fid, int flags); int handleAvailable(jlong fd, jlong *pbytes); JNIEXPORT int handleSync(jlong fd); int handleSetLength(jlong fd, jlong length); -JNIEXPORT size_t handleRead(jlong fd, void *buf, jint len); -JNIEXPORT size_t handleWrite(jlong fd, const void *buf, jint len); +JNIEXPORT SSIZE_T handleRead(jlong fd, void *buf, jint len); +JNIEXPORT SSIZE_T handleWrite(jlong fd, const void *buf, jint len); jint handleClose(JNIEnv *env, jobject this, jfieldID fid); jlong handleLseek(jlong fd, jlong offset, jint whence); /* * Returns an opaque handle to file named by "path". If an error occurs, * returns -1 and an exception is pending. --- E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.c~ 2011-11-15 16:02:55.000000000 +0800 +++ E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.c 2011-11-15 16:03:08.000000000 +0800 @@ -484,13 +484,13 @@ } if (SetEndOfFile(h) == FALSE) return -1; return 0; } JNIEXPORT -size_t +SSIZE_T handleRead(jlong fd, void *buf, jint len) { DWORD read = 0; BOOL result = 0; HANDLE h = (HANDLE)fd; if (h == INVALID_HANDLE_VALUE) { @@ -509,13 +509,13 @@ return -1; } return read; } JNIEXPORT -size_t +SSIZE_T handleWrite(jlong fd, const void *buf, jint len) { BOOL result = 0; DWORD written = 0; HANDLE h = (HANDLE)fd; if (h != INVALID_HANDLE_VALUE) { I will put it on the bug system. On 2011/11/9 16:57, Jing Lv wrote: > Hello Alan, > > (Sorry that haven't check this for months) I check with the bug > 7030624 but see no progress now. What's the current status? Shall we > go on with a simple patch to fix the problem? > > > On 2011/7/21 21:32, Alan Bateman wrote: >> Jing LV wrote: >>> Ping, anyone notice this? :) >>> My plan is that we'd search all source to find all kinds of such >>> issues, and then refine them in a uniform solution. If jint is not >>> good enough, how about ssize_t? >> ACK, saw your mails and will get back to you soon on this. >> >> -Alan > From gary.adams at oracle.com Tue Nov 15 12:03:33 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 15 Nov 2011 07:03:33 -0500 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC17AD4.80800@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC17AD4.80800@oracle.com> Message-ID: <4EC25515.7000200@oracle.com> Updated again with comment and cosmetic changes. Waiting for Alan's input on whether @bug tag includes bugfixes against the test or only the original functional bug report. On 11/14/11 03:32 PM, Gary Adams wrote: > Updated to move static latch to Copier > constructor argument. > > On 11/14/11 11:09 AM, Gary Adams wrote: >> I've updated the webrev for CR#6860309 using a CountDownLatch. >> The main thread will wait til both worker threads are ready to >> block on the read() before the process is destroyed. >> >> http://cr.openjdk.java.net/~gadams/6860309/ >> >> Tested with -Xcomp, but still may need a older slow solaris/sparc >> machine to confirm the fix works for the original bug >> submitter. >> > From gary.adams at oracle.com Tue Nov 15 12:26:00 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 15 Nov 2011 07:26:00 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EBBE286.10109@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> Message-ID: <4EC25A58.6030601@oracle.com> Added PlatformLoggingMXBeanTest to the 7067691 bug fix, e.g. instance variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ Fresh webrevs for the other work in progress bug fixes. http://cr.openjdk.java.net/~gadams/6731620/ http://cr.openjdk.java.net/~gadams/6818464/ http://cr.openjdk.java.net/~gadams/6860309/ http://cr.openjdk.java.net/~gadams/7084033/ On 11/10/11 09:41 AM, Gary Adams wrote: > On 11/ 8/11 11:13 PM, Mandy Chung wrote: >> >> >> Thanks for picking up this bug and fixing this intermittent issue. >> PlatformLoggingMXBeanTest.java in the same directory has the same issue. >> It'd be good to fix that with the same CR. These tests were copied from >> test/java/util/logging/LoggingMXBeanTest.java. I haven't looked in details >> but I wonder why the test/java/util/logging tests don't have this >> intermittent issue and I suspect it holds a strong reference. > > I attempted to break PlatformLoggingMXBeanTest.java with a generous > application of > GC calls, but I could not get it to fail in the same manner as the other test. > It may be > failing due to a different condition. > From Alan.Bateman at oracle.com Tue Nov 15 13:26:44 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 13:26:44 +0000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC1B8D5.2020104@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> Message-ID: <4EC26894.1020500@oracle.com> On 15/11/2011 00:56, David Holmes wrote: > : > 25 * @bug 4820217 6860309 > > As per other emails and still waiting from confirmation from Alan. I > don't think the @bug should be updated for any of these test fixes. The @bug tag is intended to list the bug numbers of bugs that are useful when you have a test failure and sometimes there can be really useful information in a bug that turns out to be a test bug. I'm not aware of any rule that says that the bug numbers shouldn't include bugs that were test only bugs but it's almost always bug numbers of bugs that caused the test to be extended to cover additional scenarios. For the tests being discussed here then I think we should just use our best judgment. Worse case it's easy to dig into the history with hg. -Alan. From Alan.Bateman at oracle.com Tue Nov 15 13:33:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 13:33:31 +0000 Subject: A method with return type size_t returns negative value In-Reply-To: <4EC21E55.3030106@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> Message-ID: <4EC26A2B.9010106@oracle.com> On 15/11/2011 08:09, Jing Lv wrote: > Hello, > > I search the E:\workspace\openjdk\jdk\src\windows\native but find > nothing similar (please tell me if I miss something), so I suggest we > have a quick fix for now, like: I'm not around this week but I will get back to you next week on this (as I may have mentioned, I had hoped we would change all of this as part of other cleanup that includes removing dependencies on the JVM* functions). -Alan. From forax at univ-mlv.fr Tue Nov 15 14:30:51 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 15 Nov 2011 15:30:51 +0100 Subject: Garbage collection race condition before final checks In-Reply-To: <4EC25A58.6030601@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> <4EC25A58.6030601@oracle.com> Message-ID: <4EC2779B.9070609@univ-mlv.fr> On 11/15/2011 01:26 PM, Gary Adams wrote: > Added PlatformLoggingMXBeanTest to the 7067691 bug fix, > e.g. instance variables for Logger variables to prevent premature > weak reference collection. > > http://cr.openjdk.java.net/~gadams/7067691/ Hi Garry, > > Fresh webrevs for the other work in progress bug fixes. > > http://cr.openjdk.java.net/~gadams/6731620/ You can declare and initialize elapsed at the same place : final long elapsed = System.currentTimeMillis() - start; otherwise, it looks ok. > http://cr.openjdk.java.net/~gadams/6818464/ if you want to have a variable changed in an inner class, the usual idiom is to use an array of one element. public static void main (String[] args) throws Exception { + final Thread[] tdThread = new Thread[1]; Timer t = new Timer(); // Start a mean event that kills the timer thread t.schedule(new TimerTask() { public void run() { + tdThread[0] = Thread.currentThread(); throw new ThreadDeath(); } }, 0); // Wait for mean event to do the deed and thread to die. try { + do { Thread.sleep(100); + } while(tdThread[0] == null); } catch(InterruptedException e) { } + tdThread[0].join(); // Try to start another event try { // Timer thread is dead now t.schedule(new TimerTask() { > http://cr.openjdk.java.net/~gadams/6860309/ This one is ok for me :) > http://cr.openjdk.java.net/~gadams/7084033/ Thumb up for this one too ! cheers, R?mi > > On 11/10/11 09:41 AM, Gary Adams wrote: >> On 11/ 8/11 11:13 PM, Mandy Chung wrote: >>> >>> >>> Thanks for picking up this bug and fixing this intermittent issue. >>> PlatformLoggingMXBeanTest.java in the same directory has the same >>> issue. It'd be good to fix that with the same CR. These tests were >>> copied from test/java/util/logging/LoggingMXBeanTest.java. I >>> haven't looked in details but I wonder why the >>> test/java/util/logging tests don't have this intermittent issue and >>> I suspect it holds a strong reference. >> >> I attempted to break PlatformLoggingMXBeanTest.java with a generous >> application of >> GC calls, but I could not get it to fail in the same manner as the >> other test. It may be >> failing due to a different condition. >> > From mandy.chung at oracle.com Tue Nov 15 17:57:19 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Nov 2011 09:57:19 -0800 Subject: Garbage collection race condition before final checks In-Reply-To: <4EC25A58.6030601@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> <4EC25A58.6030601@oracle.com> Message-ID: <4EC2A7FF.4010708@oracle.com> On 11/15/11 04:26, Gary Adams wrote: > Added PlatformLoggingMXBeanTest to the 7067691 bug fix, > e.g. instance variables for Logger variables to prevent premature > weak reference collection. > > http://cr.openjdk.java.net/~gadams/7067691/ LoggingMXBeanTest.java: As Alan suggests, it'd be better to rename "lmxbeantest". I think simply "test" would do it. L70: resetting null is not needed. L232, 234: "(" and ")" brackets don't seem to be needed PlatformLoggingMXBeanTest.java: Similar comments as I gave to LoggingMXBeanTest.java: need to add the CR # to @bug. L48-49: a comment will prevent someone to back out this change to keep a strong reference in the future. Are you able to reproduce the test failure without moving L140-141? Mandy From gary.adams at oracle.com Tue Nov 15 18:20:09 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 15 Nov 2011 13:20:09 -0500 Subject: Garbage collection race condition before final checks In-Reply-To: <4EC2A7FF.4010708@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> <4EC25A58.6030601@oracle.com> <4EC2A7FF.4010708@oracle.com> Message-ID: <4EC2AD59.9070407@oracle.com> Updated the webrev - renamed variable to "test" - removed reset to null - removed extra parens in exception message - updated @bug tag I have never seen the failure with PlatformLoggingMXBeanTest, and I had previously done a gc right after the Logger assignment. Seems to be a reasonable update to use the instance variables in case the previous failures were caused by the logger being gc'ed. On 11/15/11 12:57 PM, Mandy Chung wrote: > On 11/15/11 04:26, Gary Adams wrote: >> Added PlatformLoggingMXBeanTest to the 7067691 bug fix, >> e.g. instance variables for Logger variables to prevent premature >> weak reference collection. >> >> http://cr.openjdk.java.net/~gadams/7067691/ > > LoggingMXBeanTest.java: As Alan suggests, it'd be better to rename > "lmxbeantest". I think simply "test" would do it. > L70: resetting null is not needed. > L232, 234: "(" and ")" brackets don't seem to be needed > > PlatformLoggingMXBeanTest.java: > Similar comments as I gave to LoggingMXBeanTest.java: need to add the CR # > to @bug. L48-49: a comment will prevent someone to back out this change to > keep a strong reference in the future. > > Are you able to reproduce the test failure without moving L140-141? > > Mandy From darryl.mocek at oracle.com Tue Nov 15 19:51:00 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Tue, 15 Nov 2011 11:51:00 -0800 Subject: Code Review Request for 6578042 In-Reply-To: <4EBE632E.8090901@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> Message-ID: <4EC2C2A4.9020909@oracle.com> I've modified the fix per feedback (thanks all). System.clearProperty now attempts to get the property with the specified key. If there is such a property, and the value is a String, remove the property and return the value removed, otherwise return null (if it is null) or throw CCE (if it's not null and is not a String...do not remove the property here). Webrev can be found here: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Darryl On 11/12/2011 04:14 AM, Alan Bateman wrote: > On 11/11/2011 19:37, Darryl Mocek wrote: >> Returning null if the value is not a String gives the impression that >> there was no property with that key when the property may have been >> there and may in fact have been removed. > That's a fair point and probably enough to conclude that this approach > should be dismissed. > > The toString approach is inconsistent so I think this brings us back > to the original suggestion which is to specify that CCE is thrown (as > it always has) but without side effects (meaning it doesn't remove the > property). I think this is the best we can do with this broken API. > > : >> >> I would prefer it if Properties didn't allow non-String keys and >> values at all since they're supposed to be Strings (by API >> implication) and that Properties not extend Hashtable or extends >> Hashtable, but I digress. > Properties goes back to JDK1.0 and has a warning in its javadoc for > many years to discourage inserting keys or values that are not > Strings. I'm not sure whether we can do much about it now without > risking compatibility issues. > > -Alan. From gary.adams at oracle.com Tue Nov 15 20:14:16 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 15 Nov 2011 15:14:16 -0500 Subject: Passing time factor to tests run under jtreg Message-ID: <4EC2C818.2060201@oracle.com> I've been scanning a number of the slow machine test bugs that are reported and wanted to check to see if anyone has looked into time dependencies in the regression tests previously. From what I've been able to learn so far individual bugs can use the "timeout" parameter to indicate to the test harness an expected time to run. The test harness has command line arguments where it can filter out tests that take too long (timelimit) or can apply a multiplier to to the timeout when conditions are known to slow down the process (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp I see that there are some wrappers that can be applied around running a particular test to allow processing before main(). Could this mechanism be exploited so the harness command line options could be made known to the time dependent tests as command line arguments or as system properties? My thought is the current timeout granularity is too large and only applies to the full test execution. If a test knew that a timeoutFactor was to be applied, it could internally adjust the time dependent delays appropriately. e.g. not every sleep(), await(), join() with timeouts would need the timeoutFactor applied. Before any test could be updated the information would need to be available from the test context. Any feedback/pointers appreciated! See timeoutFactorArg jtreg/src/share/classes/com/sun/javatest/regtest/Main.java runOtherJVM() jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java maxTimeoutValue jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java From david.holmes at oracle.com Tue Nov 15 21:29:29 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 07:29:29 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC26894.1020500@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> Message-ID: <4EC2D9B9.70700@oracle.com> Alan, On 15/11/2011 11:26 PM, Alan Bateman wrote: > On 15/11/2011 00:56, David Holmes wrote: >> : >> 25 * @bug 4820217 6860309 >> >> As per other emails and still waiting from confirmation from Alan. I >> don't think the @bug should be updated for any of these test fixes. > The @bug tag is intended to list the bug numbers of bugs that are useful > when you have a test failure and sometimes there can be really useful > information in a bug that turns out to be a test bug. I'm not aware of > any rule that says that the bug numbers shouldn't include bugs that were > test only bugs but it's almost always bug numbers of bugs that caused > the test to be extended to cover additional scenarios. For the tests > being discussed here then I think we should just use our best judgment. > Worse case it's easy to dig into the history with hg. That was somewhat non-committal :) To me @bug says "these are the bugs that this test is checking the fix for" hence not applicable in any of the recent timing/race test fixes. David > -Alan. From gary.adams at oracle.com Tue Nov 15 21:38:28 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 15 Nov 2011 16:38:28 -0500 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC2D9B9.70700@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> <4EC2D9B9.70700@oracle.com> Message-ID: <4EC2DBD4.5030504@oracle.com> Where can we find the definition of the tag contents? Whichever way this discussion goes, we should update that documentation with the conclusions. On 11/15/11 4:29 PM, David Holmes wrote: > Alan, > > On 15/11/2011 11:26 PM, Alan Bateman wrote: >> On 15/11/2011 00:56, David Holmes wrote: >>> : >>> 25 * @bug 4820217 6860309 >>> >>> As per other emails and still waiting from confirmation from Alan. I >>> don't think the @bug should be updated for any of these test fixes. >> The @bug tag is intended to list the bug numbers of bugs that are useful >> when you have a test failure and sometimes there can be really useful >> information in a bug that turns out to be a test bug. I'm not aware of >> any rule that says that the bug numbers shouldn't include bugs that were >> test only bugs but it's almost always bug numbers of bugs that caused >> the test to be extended to cover additional scenarios. For the tests >> being discussed here then I think we should just use our best judgment. >> Worse case it's easy to dig into the history with hg. > > That was somewhat non-committal :) To me @bug says "these are the bugs > that this test is checking the fix for" hence not applicable in any of > the recent timing/race test fixes. > > David > >> -Alan. From Alan.Bateman at oracle.com Tue Nov 15 22:29:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 22:29:57 +0000 Subject: Code Review Request for 6578042 In-Reply-To: <4EC2C2A4.9020909@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC2C2A4.9020909@oracle.com> Message-ID: <4EC2E7E5.8060509@oracle.com> On 15/11/2011 19:51, Darryl Mocek wrote: > I've modified the fix per feedback (thanks all). System.clearProperty > now attempts to get the property with the specified key. If there is > such a property, and the value is a String, remove the property and > return the value removed, otherwise return null (if it is null) or > throw CCE (if it's not null and is not a String...do not remove the > property here). Webrev can be found here: > > http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Thanks for changing the approach, I think this is much better. On the implementation then I assume you need to synchronize around the get+remove. The regression tests isn't in this webrev but you might want to go back over the comments on the original test. Also didn't we agree to also update Properties.getProperty to make it clear that it returns null when the value is not a String? -Alan From Alan.Bateman at oracle.com Tue Nov 15 22:37:20 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 22:37:20 +0000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC2D9B9.70700@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> <4EC2D9B9.70700@oracle.com> Message-ID: <4EC2E9A0.1000009@oracle.com> On 15/11/2011 21:29, David Holmes wrote: > > That was somewhat non-committal :) To me @bug says "these are the bugs > that this test is checking the fix for" hence not applicable in any of > the recent timing/race test fixes. It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. -Alan. From Alan.Bateman at oracle.com Tue Nov 15 22:45:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Nov 2011 22:45:03 +0000 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC2C818.2060201@oracle.com> References: <4EC2C818.2060201@oracle.com> Message-ID: <4EC2EB6F.90805@oracle.com> Gary - this might be something to bring up on the jtreg-use list. Ideally the tests wouldn't have any hardcoded timeouts but sometimes there isn't any other choice. -Alan On 15/11/2011 20:14, Gary Adams wrote: > I've been scanning a number of the slow machine test > bugs that are reported and wanted to check to see if > anyone has looked into time dependencies in the regression > tests previously. From what I've been able to learn so far > individual bugs can use the "timeout" parameter to indicate to > the test harness an expected time to run. > > The test harness has command line arguments where it can > filter out tests that take too long (timelimit) or can apply a > multiplier to > to the timeout when conditions are known to slow down the process > (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp > > I see that there are some wrappers that can be applied around running > a particular test to allow processing before main(). Could this mechanism > be exploited so the harness command line options could be made known > to the time dependent tests as command line arguments or as system > properties? > > My thought is the current timeout granularity is too large and only > applies > to the full test execution. If a test knew that a timeoutFactor was to > be applied, > it could internally adjust the time dependent delays appropriately. e.g. > not every sleep(), await(), join() with timeouts would need the > timeoutFactor > applied. > > Before any test could be updated the information would need to be > available > from the test context. > > Any feedback/pointers appreciated! > > > See > timeoutFactorArg > jtreg/src/share/classes/com/sun/javatest/regtest/Main.java > runOtherJVM() > jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java > maxTimeoutValue > > jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java > > From david.holmes at oracle.com Wed Nov 16 00:06:36 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 10:06:36 +1000 Subject: Garbage collection race condition before final checks In-Reply-To: <4EC2779B.9070609@univ-mlv.fr> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> <4EC25A58.6030601@oracle.com> <4EC2779B.9070609@univ-mlv.fr> Message-ID: <4EC2FE8C.1050708@oracle.com> Gary: Please do not start discussing other bugs in this thread - please keep them distinct. Remi: please add any comments to the discussion threads on those other bugs. Thanks David On 16/11/2011 12:30 AM, R?mi Forax wrote: > On 11/15/2011 01:26 PM, Gary Adams wrote: >> Added PlatformLoggingMXBeanTest to the 7067691 bug fix, >> e.g. instance variables for Logger variables to prevent premature >> weak reference collection. >> >> http://cr.openjdk.java.net/~gadams/7067691/ > > Hi Garry, > >> >> Fresh webrevs for the other work in progress bug fixes. >> >> http://cr.openjdk.java.net/~gadams/6731620/ > > You can declare and initialize elapsed at the same place : > final long elapsed = System.currentTimeMillis() - start; > otherwise, it looks ok. > >> http://cr.openjdk.java.net/~gadams/6818464/ > > if you want to have a variable changed in an inner class, the usual idiom > is to use an array of one element. > > public static void main (String[] args) throws Exception { > + final Thread[] tdThread = new Thread[1]; > Timer t = new Timer(); > > // Start a mean event that kills the timer thread > t.schedule(new TimerTask() { > public void run() { > + tdThread[0] = Thread.currentThread(); > throw new ThreadDeath(); > } > }, 0); > > // Wait for mean event to do the deed and thread to die. > try { > + do { > Thread.sleep(100); > + } while(tdThread[0] == null); > } catch(InterruptedException e) { > } > + tdThread[0].join(); > > // Try to start another event > try { > // Timer thread is dead now > t.schedule(new TimerTask() { > > > >> http://cr.openjdk.java.net/~gadams/6860309/ > > This one is ok for me :) > >> http://cr.openjdk.java.net/~gadams/7084033/ > > Thumb up for this one too ! > > cheers, > R?mi > >> >> On 11/10/11 09:41 AM, Gary Adams wrote: >>> On 11/ 8/11 11:13 PM, Mandy Chung wrote: >>>> >>>> >>>> Thanks for picking up this bug and fixing this intermittent issue. >>>> PlatformLoggingMXBeanTest.java in the same directory has the same >>>> issue. It'd be good to fix that with the same CR. These tests were >>>> copied from test/java/util/logging/LoggingMXBeanTest.java. I haven't >>>> looked in details but I wonder why the test/java/util/logging tests >>>> don't have this intermittent issue and I suspect it holds a strong >>>> reference. >>> >>> I attempted to break PlatformLoggingMXBeanTest.java with a generous >>> application of >>> GC calls, but I could not get it to fail in the same manner as the >>> other test. It may be >>> failing due to a different condition. >>> >> > From iris.clark at oracle.com Wed Nov 16 00:47:50 2011 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 15 Nov 2011 16:47:50 -0800 (PST) Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: <4EC2E9A0.1000009@oracle.com> References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> <4EC2D9B9.70700@oracle.com 4EC2E9A0.1000009@oracle.com> Message-ID: Hi. The current practice may be different, but... The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: http://openjdk.java.net/guide/changePlanning.html#bug In the case of bugs against regression tests I've seen two approaches: 1. Addition of the bugid to the @bug tag 2. Addition of the "noreg-self" keyword to bugtraq Both technically fulfill the original intent. At one point there were audits to enforce this. Knowing how the audits worked (I personally preformed them for a while), I tended to favor adding the bugid to @bug as that would minimize the number of BugTraq queries. Even when the network and BugTraq were functioning perfectly, a BugTraq query always took longer than just looking at the source (which we were already looking at). Again, the above may no longer be the current practice or recommendation. Thanks, iris -----Original Message----- From: Alan Bateman Sent: Tuesday, November 15, 2011 2:37 PM To: David Holmes Cc: Gary Adams; core-libs-dev at openjdk.java.net Subject: Re: CR 6860309 - solaris timing issue on thread startup On 15/11/2011 21:29, David Holmes wrote: > > That was somewhat non-committal :) To me @bug says "these are the bugs > that this test is checking the fix for" hence not applicable in any of > the recent timing/race test fixes. It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. -Alan. From david.holmes at oracle.com Wed Nov 16 01:17:14 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 11:17:14 +1000 Subject: Code Review Request for 6578042 In-Reply-To: <4EC2E7E5.8060509@oracle.com> References: <4EB031BB.8020608@oracle.com> <4EB086BB.3050608@oracle.com> <4EB111C6.8000008@oracle.com> <4EB1A112.3070102@oracle.com> <4EB6653A.7020405@oracle.com> <4EBD796A.3040400@oracle.com> <4EBE632E.8090901@oracle.com> <4EC2C2A4.9020909@oracle.com> <4EC2E7E5.8060509@oracle.com> Message-ID: <4EC30F1A.6070308@oracle.com> On 16/11/2011 8:29 AM, Alan Bateman wrote: > On 15/11/2011 19:51, Darryl Mocek wrote: >> I've modified the fix per feedback (thanks all). System.clearProperty >> now attempts to get the property with the specified key. If there is >> such a property, and the value is a String, remove the property and >> return the value removed, otherwise return null (if it is null) or >> throw CCE (if it's not null and is not a String...do not remove the >> property here). Webrev can be found here: >> >> http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev > Thanks for changing the approach, I think this is much better. On the > implementation then I assume you need to synchronize around the > get+remove. Yes - as it stands this is not thread-safe. Ideally I'd prefer to see the desired behaviour encapsulated in the Properties class (override Hashtable.remove) so that the synchronization is handled there too - but that may be too big an ask. Also needs a CCC for the spec change. Thanks, David The regression tests isn't in this webrev but you might want > to go back over the comments on the original test. Also didn't we agree > to also update Properties.getProperty to make it clear that it returns > null when the value is not a String? > > -Alan From david.holmes at oracle.com Wed Nov 16 01:33:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 11:33:12 +1000 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC2C818.2060201@oracle.com> References: <4EC2C818.2060201@oracle.com> Message-ID: <4EC312D8.4060406@oracle.com> Hi Gary, On 16/11/2011 6:14 AM, Gary Adams wrote: > I've been scanning a number of the slow machine test > bugs that are reported and wanted to check to see if > anyone has looked into time dependencies in the regression > tests previously. From what I've been able to learn so far > individual bugs can use the "timeout" parameter to indicate to > the test harness an expected time to run. > > The test harness has command line arguments where it can > filter out tests that take too long (timelimit) or can apply a > multiplier to > to the timeout when conditions are known to slow down the process > (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp > > I see that there are some wrappers that can be applied around running > a particular test to allow processing before main(). Could this mechanism > be exploited so the harness command line options could be made known > to the time dependent tests as command line arguments or as system > properties? > > My thought is the current timeout granularity is too large and only applies > to the full test execution. If a test knew that a timeoutFactor was to > be applied, > it could internally adjust the time dependent delays appropriately. e.g. > not every sleep(), await(), join() with timeouts would need the > timeoutFactor applied. I don't quite get what you mean about the timeouts applied to sleeps, awaits etc. Depending on the test some of these are delays (eg sleep is usually used this way) because it may not be feasible (or even possible) to coordinate the threads directly; while others (await, wait etc) are actual timeouts - if they expire it is an error because something appears to have gone wrong somewhere (of course this can be wrong because the timeout was too short for a given situation). As many of these tests have evolved along with the testing infrastructure it isn't always very clear who has responsibility for programming defensive timeouts. And many tests are designed to be run stand-alone or under a test harness, where exceptions due to timeouts are preferable to hangs. Further, while we can add a scale factor for known retarding factors - like Xcomp - there's no general way to assess the target machine capability (# cores, speed) and load, as it may impact a given test. And historically there has been a lack of resources to investigate and solve these issues. Cheers, David > Before any test could be updated the information would need to be available > from the test context. > > Any feedback/pointers appreciated! > > > See > timeoutFactorArg > jtreg/src/share/classes/com/sun/javatest/regtest/Main.java > runOtherJVM() > jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java > maxTimeoutValue > jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java > > From david.holmes at oracle.com Wed Nov 16 01:44:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 11:44:16 +1000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> <4EC2D9B9.70700@oracle.com 4EC2E9A0.1000009@oracle.com> Message-ID: <4EC31570.7000804@oracle.com> Hi Iris, Still seems to me, based on the FAQ, http://openjdk.java.net/jtreg/faq.html that the intent is for @bug to refer to the bug that the test is testing. But as it is looking like this has been used in an ad-hoc manner anyway I'll shut up now. ;-) Cheers, David On 16/11/2011 10:47 AM, Iris Clark wrote: > Hi. > > The current practice may be different, but... > > The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: > > http://openjdk.java.net/guide/changePlanning.html#bug > > In the case of bugs against regression tests I've seen two approaches: > > 1. Addition of the bugid to the @bug tag > 2. Addition of the "noreg-self" keyword to bugtraq > > Both technically fulfill the original intent. At one point there were audits to enforce this. > > Knowing how the audits worked (I personally preformed them for a while), I tended to favor adding the bugid to @bug as that would minimize the number of BugTraq queries. Even when the network and BugTraq were functioning perfectly, a BugTraq query always took longer than just looking at the source (which we were already looking at). > > Again, the above may no longer be the current practice or recommendation. > > Thanks, > iris > > -----Original Message----- > From: Alan Bateman > Sent: Tuesday, November 15, 2011 2:37 PM > To: David Holmes > Cc: Gary Adams; core-libs-dev at openjdk.java.net > Subject: Re: CR 6860309 - solaris timing issue on thread startup > > On 15/11/2011 21:29, David Holmes wrote: >> >> That was somewhat non-committal :) To me @bug says "these are the bugs >> that this test is checking the fix for" hence not applicable in any of >> the recent timing/race test fixes. > It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. > > -Alan. From weijun.wang at oracle.com Wed Nov 16 03:54:35 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 16 Nov 2011 03:54:35 +0000 Subject: hg: jdk8/tl/jdk: 7111579: klist starttime, renewtill, ticket etype Message-ID: <20111116035453.EF98B4738A@hg.openjdk.java.net> Changeset: c740519fe83a Author: weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java From masayoshi.okutsu at oracle.com Wed Nov 16 04:31:00 2011 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Wed, 16 Nov 2011 04:31:00 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111116043119.9EFE64738B@hg.openjdk.java.net> Changeset: cd6d236e863b Author: okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author: okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1266e72f7896 Merge From weijun.wang at oracle.com Wed Nov 16 04:55:54 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Nov 2011 12:55:54 +0800 Subject: what is the most precise time I can get in JDK? Message-ID: <4EC3425A.6040805@oracle.com> Hi All I need a precise time, and is currently using java.util.Date, which knows about milliseconds, but unfortunately the precision is only 10-15 milliseconds on a Windows. In fact, I don't really need it to be so correct. My requirements are: 1. It's enough correct, say, at least as correct as Date. 2. It's precise in a relative sense, i.e. it changes fast 3. It should be monotonic, i.e. it grows, unless the user adjusts the system clock Thanks Max From David.Holmes at oracle.com Wed Nov 16 07:23:18 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 17:23:18 +1000 Subject: what is the most precise time I can get in JDK? In-Reply-To: <4EC3425A.6040805@oracle.com> References: <4EC3425A.6040805@oracle.com> Message-ID: <4EC364E6.50400@oracle.com> Hi Max, On 16/11/2011 2:55 PM, Weijun Wang wrote: > I need a precise time, and is currently using java.util.Date, which knows > about milliseconds, but unfortunately the precision is only 10-15 > milliseconds on a Windows. > > In fact, I don't really need it to be so correct. My requirements are: > > 1. It's enough correct, say, at least as correct as Date. > 2. It's precise in a relative sense, i.e. it changes fast > 3. It should be monotonic, i.e. it grows, unless the user adjusts the system > clock There are only two time source available: 1. The time-of-day clock This is what Date reports and is also what System.currentTimeMillis reports. It only has millisecond precision. It's rate of update is dependent on the OS - for Windows that is typically every 10ms or every 15ms depending on version. 2. The high resolution time source This is what System.nanoTime reports. It has nanosecond precision, but again depending on the OS it's resolution (update rate) will vary. The update rate should easily be in the tens of microseconds. It should be monotonic non-decreasing but it is not connected to the time-of-day clock (and so should not be affected by any changes therein). I have an old blog entry on this: http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks David ----- From Alan.Bateman at oracle.com Wed Nov 16 07:53:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2011 07:53:13 +0000 Subject: CR 6860309 - solaris timing issue on thread startup In-Reply-To: References: <4EBD53D0.6050808@oracle.com> <4EBE5F73.706@oracle.com> <4EBE625E.80308@oracle.com> <4EC13D4F.8010108@oracle.com> <4EC1B8D5.2020104@oracle.com> <4EC26894.1020500@oracle.com> <4EC2D9B9.70700@oracle.com 4EC2E9A0.1000009@oracle.com> Message-ID: <4EC36BE9.2040907@oracle.com> On 16/11/2011 00:47, Iris Clark wrote: > Hi. > > The current practice may be different, but... > > The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: > > http://openjdk.java.net/guide/changePlanning.html#bug This is the still the current practice and of course a specific regression test may be for several bugs (as often it make more sense to add to an existing test rather than add a new test each time). > In the case of bugs against regression tests I've seen two approaches: > > 1. Addition of the bugid to the @bug tag > 2. Addition of the "noreg-self" keyword to bugtraq > > Both technically fulfill the original intent. At one point there were audits to enforce this. There are still checks that noreg-self is added to the bug. I don't think the option of adding the bug number to @bug has been written down as an option, or at least I don't recall it coming up. I don't think it matters too much, the main intent is to give future maintainers the list of interesting bugs in the event of a test failure. -Alan From weijun.wang at oracle.com Wed Nov 16 08:09:22 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 16 Nov 2011 16:09:22 +0800 Subject: what is the most precise time I can get in JDK? In-Reply-To: <4EC364E6.50400@oracle.com> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> Message-ID: <4EC36FB2.80508@oracle.com> Hi Davis Yes, I know nanoTime() is precise, but how can I get a clock time from it? I have tried to record a currentTimeMillis() value when the program starts and then use the elapse of the nanaTime() to get a current time. This will break if the user adjusts the system clock during the program execution. One solution is to keep tracking the changing of both currentTimeMillis() and nanoTime(). If the change of one has a difference (say, > 1 sec) from the other one, it means a system clock change and I can quickly reset my time to currentTimeMillis(). Thanks Max On 11/16/2011 03:23 PM, David Holmes wrote: > Hi Max, > > On 16/11/2011 2:55 PM, Weijun Wang wrote: >> I need a precise time, and is currently using java.util.Date, which knows >> about milliseconds, but unfortunately the precision is only 10-15 >> milliseconds on a Windows. >> >> In fact, I don't really need it to be so correct. My requirements are: >> >> 1. It's enough correct, say, at least as correct as Date. >> 2. It's precise in a relative sense, i.e. it changes fast >> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >> system >> clock > > There are only two time source available: > > 1. The time-of-day clock > > This is what Date reports and is also what System.currentTimeMillis > reports. It only has millisecond precision. It's rate of update is > dependent on the OS - for Windows that is typically every 10ms or every > 15ms depending on version. > > 2. The high resolution time source > > This is what System.nanoTime reports. It has nanosecond precision, but > again depending on the OS it's resolution (update rate) will vary. The > update rate should easily be in the tens of microseconds. It should be > monotonic non-decreasing but it is not connected to the time-of-day > clock (and so should not be affected by any changes therein). > > I have an old blog entry on this: > > http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks > > David > ----- From David.Holmes at oracle.com Wed Nov 16 08:42:13 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Nov 2011 18:42:13 +1000 Subject: what is the most precise time I can get in JDK? In-Reply-To: <4EC36FB2.80508@oracle.com> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> <4EC36FB2.80508@oracle.com> Message-ID: <4EC37765.8000108@oracle.com> On 16/11/2011 6:09 PM, Weijun Wang wrote: > Yes, I know nanoTime() is precise, but how can I get a clock time from it? I > have tried to record a currentTimeMillis() value when the program starts and > then use the elapse of the nanaTime() to get a current time. This will break > if the user adjusts the system clock during the program execution. > One solution is to keep tracking the changing of both currentTimeMillis() > and nanoTime(). If the change of one has a difference (say, > 1 sec) from > the other one, it means a system clock change and I can quickly reset my > time to currentTimeMillis(). What you have tried is pretty much all you can do. nanoTime is not connected to to the time-of-day. If you need to make a connection then you need to make it and keep it synchronized. David ----- > Thanks > Max > > > > On 11/16/2011 03:23 PM, David Holmes wrote: >> Hi Max, >> >> On 16/11/2011 2:55 PM, Weijun Wang wrote: >>> I need a precise time, and is currently using java.util.Date, which knows >>> about milliseconds, but unfortunately the precision is only 10-15 >>> milliseconds on a Windows. >>> >>> In fact, I don't really need it to be so correct. My requirements are: >>> >>> 1. It's enough correct, say, at least as correct as Date. >>> 2. It's precise in a relative sense, i.e. it changes fast >>> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >>> system >>> clock >> >> There are only two time source available: >> >> 1. The time-of-day clock >> >> This is what Date reports and is also what System.currentTimeMillis >> reports. It only has millisecond precision. It's rate of update is >> dependent on the OS - for Windows that is typically every 10ms or every >> 15ms depending on version. >> >> 2. The high resolution time source >> >> This is what System.nanoTime reports. It has nanosecond precision, but >> again depending on the OS it's resolution (update rate) will vary. The >> update rate should easily be in the tens of microseconds. It should be >> monotonic non-decreasing but it is not connected to the time-of-day >> clock (and so should not be affected by any changes therein). >> >> I have an old blog entry on this: >> >> http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks >> >> David >> ----- From gary.adams at oracle.com Wed Nov 16 12:53:50 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Nov 2011 07:53:50 -0500 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC312D8.4060406@oracle.com> References: <4EC2C818.2060201@oracle.com> <4EC312D8.4060406@oracle.com> Message-ID: <4EC3B25E.2050409@oracle.com> On 11/15/11 8:33 PM, David Holmes wrote: > Hi Gary, > > On 16/11/2011 6:14 AM, Gary Adams wrote: >> I've been scanning a number of the slow machine test >> bugs that are reported and wanted to check to see if >> anyone has looked into time dependencies in the regression >> tests previously. From what I've been able to learn so far >> individual bugs can use the "timeout" parameter to indicate to >> the test harness an expected time to run. >> >> The test harness has command line arguments where it can >> filter out tests that take too long (timelimit) or can apply a >> multiplier to >> to the timeout when conditions are known to slow down the process >> (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp >> >> I see that there are some wrappers that can be applied around running >> a particular test to allow processing before main(). Could this >> mechanism >> be exploited so the harness command line options could be made known >> to the time dependent tests as command line arguments or as system >> properties? >> >> My thought is the current timeout granularity is too large and only >> applies >> to the full test execution. If a test knew that a timeoutFactor was to >> be applied, >> it could internally adjust the time dependent delays appropriately. e.g. >> not every sleep(), await(), join() with timeouts would need the >> timeoutFactor applied. > > I don't quite get what you mean about the timeouts applied to sleeps, > awaits etc. Depending on the test some of these are delays (eg sleep > is usually used this way) because it may not be feasible (or even > possible) to coordinate the threads directly; while others (await, > wait etc) are actual timeouts - if they expire it is an error because > something appears to have gone wrong somewhere (of course this can be > wrong because the timeout was too short for a given situation). The timeout being too short for a slow machine is the specific condition I'd like to address. > > As many of these tests have evolved along with the testing > infrastructure it isn't always very clear who has responsibility for > programming defensive timeouts. And many tests are designed to be run > stand-alone or under a test harness, where exceptions due to timeouts > are preferable to hangs. Some of the bug reports state an intermittent failure. Could be failing due to busy machine, slow machine or aggressive command line options. If a test has an advertized timeout, then it needs to be run stand-alone. If aggressive command line options are used the timefactor multiplier can compensate for the whole test timeout. I believe we can identify slow machines and apply the same timefactor multiplier. > > Further, while we can add a scale factor for known retarding factors - > like Xcomp - there's no general way to assess the target machine > capability (# cores, speed) and load, as it may impact a given test. > And historically there has been a lack of resources to investigate and > solve these issues. I'm not sure why test machine characteristics are not known at test time. Obviously some agent setup has been done to identify chip architecture and operating system. The cpu speed is just another attribute of the test machine. I understand the lack of resources to address this area in the past, but resources are being applied to ensure jdk8 is appropriate for embedded deployments. This seems like another low hanging fruit. e.g. not technically difficult, not particularly controversial > > Cheers, > David > >> Before any test could be updated the information would need to be >> available >> from the test context. >> >> Any feedback/pointers appreciated! >> >> >> See >> timeoutFactorArg >> jtreg/src/share/classes/com/sun/javatest/regtest/Main.java >> runOtherJVM() >> jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java >> maxTimeoutValue >> jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java >> >> >> From gary.adams at oracle.com Wed Nov 16 16:29:34 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Nov 2011 11:29:34 -0500 Subject: Potential timeout issues - tests running in the same vm Message-ID: <4EC3E4EE.5060902@oracle.com> The jtreg tests that use othervm along with a timeout argument should be fairly reliable in getting a consistent result. The tests that did not specify othervm may run into problems, if they are run concurrently with other tests. Here's a quick sampling of the java/util and java/lang tests that might have issues. Would there be any harm in changing these to designate running in othervm mode? find jdk/test/java/{util,lang} -type f |grep -v hg/|xargs grep -n @run |grep timeout |egrep -v "othervm|shell" jdk/test/java/util/ResourceBundle/Bug4168625Test.java:27: @run main/timeout=600 Bug4168625Test jdk/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java:38: * @run main/timeout=7000 CancelledProducerConsumerLoops jdk/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java:38: * @run main/timeout=3600 MultipleProducersSingleConsumerLoops jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java:38: * @run main/timeout=3600 ProducerConsumerLoops jdk/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java:38: * @run main/timeout=600 SingleProducerMultipleConsumerLoops jdk/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java:38: * @run main/timeout=240 MapCheck jdk/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java:38: * @run main/timeout=1600 MapLoops jdk/test/java/util/concurrent/Exchanger/ExchangeLoops.java:38: * @run main/timeout=720 ExchangeLoops jdk/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java:38: * @run main/timeout=3600 ExecutorCompletionServiceLoops jdk/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java:38: * @run main/timeout=2000 CancelledFutureLoops jdk/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java:38: * @run main/timeout=2800 CancelledLockLoops jdk/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java:38: * @run main/timeout=15000 LockOncePerThreadLoops jdk/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java:38: * @run main/timeout=4500 SimpleReentrantLockLoops jdk/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java:38: * @run main/timeout=4700 MapLoops jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run main/timeout=15 LoggingDeadlock jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run main/timeout=15 LoggingDeadlock2 jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run main/timeout=80 LoggingDeadlock3 jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run main/timeout=15 LoggingDeadlock4 jdk/test/java/util/zip/ZipFile/ManyEntries.java:27: * @run main/timeout=600 ManyEntries jdk/test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java:29: * @run main/timeout=30 FoundType jdk/test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java:34: * @run main/timeout=300 CollectionUsageThreshold From Alan.Bateman at oracle.com Wed Nov 16 16:56:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2011 16:56:28 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3E4EE.5060902@oracle.com> References: <4EC3E4EE.5060902@oracle.com> Message-ID: <4EC3EB3C.3000608@oracle.com> On 16/11/2011 16:29, Gary Adams wrote: > > The jtreg tests that use othervm along with a timeout argument should be > fairly reliable in getting a consistent result. The tests that did not > specify > othervm may run into problems, if they are run concurrently with other > tests. > > Here's a quick sampling of the java/util and java/lang tests that > might have issues. > Would there be any harm in changing these to designate running in > othervm mode? With jtreg then tests don't run concurrently in the same VM. By default then each test is run in its own VM, unless you use the -samevm or -agentvm options, in which case the tests run sequentially in the same (or an agent) VM -- ie: othervm is the default. So I don't think there is a problem and we definitely don't want to add /othervm to tests if we can avoid it (as it slows down the test execution). -Alan From kelly.ohair at oracle.com Wed Nov 16 16:59:52 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 16 Nov 2011 08:59:52 -0800 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3E4EE.5060902@oracle.com> References: <4EC3E4EE.5060902@oracle.com> Message-ID: <74A98A8E-25DF-458C-AE3B-F12FA7DB6423@oracle.com> On Nov 16, 2011, at 8:29 AM, Gary Adams wrote: > > The jtreg tests that use othervm along with a timeout argument should be > fairly reliable in getting a consistent result. The tests that did not specify > othervm may run into problems, if they are run concurrently with other tests. > > Here's a quick sampling of the java/util and java/lang tests that might have issues. > Would there be any harm in changing these to designate running in othervm mode? My general feeling is 'No harm', looking at this list (somewhat short anyway) these tests seem like good candidates to be othervm tests anyway. but that's just my opinion. -kto > > find jdk/test/java/{util,lang} -type f |grep -v hg/|xargs grep -n @run |grep timeout |egrep -v "othervm|shell" > > jdk/test/java/util/ResourceBundle/Bug4168625Test.java:27: @run main/timeout=600 Bug4168625Test > jdk/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java:38: * @run main/timeout=7000 CancelledProducerConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java:38: * @run main/timeout=3600 MultipleProducersSingleConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java:38: * @run main/timeout=3600 ProducerConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java:38: * @run main/timeout=600 SingleProducerMultipleConsumerLoops > jdk/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java:38: * @run main/timeout=240 MapCheck > jdk/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java:38: * @run main/timeout=1600 MapLoops > jdk/test/java/util/concurrent/Exchanger/ExchangeLoops.java:38: * @run main/timeout=720 ExchangeLoops > jdk/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java:38: * @run main/timeout=3600 ExecutorCompletionServiceLoops > jdk/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java:38: * @run main/timeout=2000 CancelledFutureLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java:38: * @run main/timeout=2800 CancelledLockLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java:38: * @run main/timeout=15000 LockOncePerThreadLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java:38: * @run main/timeout=4500 SimpleReentrantLockLoops > jdk/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java:38: * @run main/timeout=4700 MapLoops > jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run main/timeout=15 LoggingDeadlock > jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run main/timeout=15 LoggingDeadlock2 > jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run main/timeout=80 LoggingDeadlock3 > jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run main/timeout=15 LoggingDeadlock4 > jdk/test/java/util/zip/ZipFile/ManyEntries.java:27: * @run main/timeout=600 ManyEntries > jdk/test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java:29: * @run main/timeout=30 FoundType > jdk/test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java:34: * @run main/timeout=300 CollectionUsageThreshold > From gary.adams at oracle.com Wed Nov 16 17:02:11 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Nov 2011 12:02:11 -0500 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3EB3C.3000608@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> Message-ID: <4EC3EC93.2040604@oracle.com> On 11/16/11 11:56 AM, Alan Bateman wrote: > On 16/11/2011 16:29, Gary Adams wrote: >> >> The jtreg tests that use othervm along with a timeout argument should be >> fairly reliable in getting a consistent result. The tests that did not specify >> othervm may run into problems, if they are run concurrently with other tests. >> >> Here's a quick sampling of the java/util and java/lang tests that might have >> issues. >> Would there be any harm in changing these to designate running in othervm mode? > With jtreg then tests don't run concurrently in the same VM. By default then > each test is run in its own VM, unless you use the -samevm or -agentvm > options, in which case the tests run sequentially in the same (or an agent) VM > -- ie: othervm is the default. So I don't think there is a problem and we > definitely don't want to add /othervm to tests if we can avoid it (as it slows > down the test execution). > > -Alan If we could demonstrate that the tests were not reliable in samevm mode on a slow machine, then there might be more evidence that these tests need to be isolated. e.g. even though the test execution is requested to be in as fast as possible configuration, the test itself may be inherently unreliable when run in that mode. From gary.adams at oracle.com Wed Nov 16 17:04:43 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Nov 2011 12:04:43 -0500 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <74A98A8E-25DF-458C-AE3B-F12FA7DB6423@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <74A98A8E-25DF-458C-AE3B-F12FA7DB6423@oracle.com> Message-ID: <4EC3ED2B.4060902@oracle.com> On 11/16/11 11:59 AM, Kelly O'Hair wrote: > On Nov 16, 2011, at 8:29 AM, Gary Adams wrote: > >> The jtreg tests that use othervm along with a timeout argument should be >> fairly reliable in getting a consistent result. The tests that did not specify >> othervm may run into problems, if they are run concurrently with other tests. >> >> Here's a quick sampling of the java/util and java/lang tests that might have issues. >> Would there be any harm in changing these to designate running in othervm mode? > My general feeling is 'No harm', looking at this list (somewhat short anyway) these tests seem like > good candidates to be othervm tests anyway. but that's just my opinion. The list is artificially shortened. I wanted to keep the thread relevant to the core libs fixes in progress for reliable tests. I also wanted to see if there was an overlap with already reported intermittent test failures. > -kto > >> find jdk/test/java/{util,lang} -type f |grep -v hg/|xargs grep -n @run |grep timeout |egrep -v "othervm|shell" >> >> jdk/test/java/util/ResourceBundle/Bug4168625Test.java:27: @run main/timeout=600 Bug4168625Test >> jdk/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java:38: * @run main/timeout=7000 CancelledProducerConsumerLoops >> jdk/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java:38: * @run main/timeout=3600 MultipleProducersSingleConsumerLoops >> jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java:38: * @run main/timeout=3600 ProducerConsumerLoops >> jdk/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java:38: * @run main/timeout=600 SingleProducerMultipleConsumerLoops >> jdk/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java:38: * @run main/timeout=240 MapCheck >> jdk/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java:38: * @run main/timeout=1600 MapLoops >> jdk/test/java/util/concurrent/Exchanger/ExchangeLoops.java:38: * @run main/timeout=720 ExchangeLoops >> jdk/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java:38: * @run main/timeout=3600 ExecutorCompletionServiceLoops >> jdk/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java:38: * @run main/timeout=2000 CancelledFutureLoops >> jdk/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java:38: * @run main/timeout=2800 CancelledLockLoops >> jdk/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java:38: * @run main/timeout=15000 LockOncePerThreadLoops >> jdk/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java:38: * @run main/timeout=4500 SimpleReentrantLockLoops >> jdk/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java:38: * @run main/timeout=4700 MapLoops >> jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run main/timeout=15 LoggingDeadlock >> jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run main/timeout=15 LoggingDeadlock2 >> jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run main/timeout=80 LoggingDeadlock3 >> jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run main/timeout=15 LoggingDeadlock4 >> jdk/test/java/util/zip/ZipFile/ManyEntries.java:27: * @run main/timeout=600 ManyEntries >> jdk/test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java:29: * @run main/timeout=30 FoundType >> jdk/test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java:34: * @run main/timeout=300 CollectionUsageThreshold >> From kelly.ohair at oracle.com Wed Nov 16 17:21:03 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 16 Nov 2011 09:21:03 -0800 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3EB3C.3000608@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> Message-ID: On Nov 16, 2011, at 8:56 AM, Alan Bateman wrote: > On 16/11/2011 16:29, Gary Adams wrote: >> >> The jtreg tests that use othervm along with a timeout argument should be >> fairly reliable in getting a consistent result. The tests that did not specify >> othervm may run into problems, if they are run concurrently with other tests. >> >> Here's a quick sampling of the java/util and java/lang tests that might have issues. >> Would there be any harm in changing these to designate running in othervm mode? > With jtreg then tests don't run concurrently in the same VM. By default then each test is run in its own VM, unless you use the -samevm or -agentvm options, in which case the tests run sequentially in the same (or an agent) VM -- ie: othervm is the default. So I don't think there is a problem and we definitely don't want to add /othervm to tests if we can avoid it (as it slows down the test execution). > > -Alan But if the test naturally runs long enough, any win from using samevm for that particular testcase is kind of minimal. And if using samevm makes the test less reliable or makes the other tests sharing it's crib less reliable, then I have no issue giving these babies their own cribs. ;^) -kto From Alan.Bateman at oracle.com Wed Nov 16 17:27:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2011 17:27:49 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3EC93.2040604@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> <4EC3EC93.2040604@oracle.com> Message-ID: <4EC3F295.8030100@oracle.com> On 16/11/2011 17:02, Gary Adams wrote: > > If we could demonstrate that the tests were not reliable in samevm mode > on a slow machine, then there might be more evidence that these tests > need to be isolated. e.g. even though the test execution is requested > to be > in as fast as possible configuration, the test itself may be > inherently unreliable > when run in that mode. If tests can't run in samevm (or agentvm) mode then they need to specify /othervm in their @run tag. Just so you know, we've put a lot of work into fixing tests so that they can run in agentvm mode (at least for the libraries, security, networking). It's unfortunate that we have some tests that can't run in samevm/agentvm mode but mostly it's because the tests change something in the environment that would cause problems for other tests or they need special environments. So are you just grep'ing the repository for tests that override the timeout or have you run into problems with these tests? -Alan. From Alan.Bateman at oracle.com Wed Nov 16 17:29:20 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2011 17:29:20 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> Message-ID: <4EC3F2F0.2020408@oracle.com> On 16/11/2011 17:21, Kelly O'Hair wrote: > : > > But if the test naturally runs long enough, any win from using samevm for that particular testcase is kind of minimal. > And if using samevm makes the test less reliable or makes the other tests sharing it's crib less reliable, > then I have no issue giving these babies their own cribs. ;^) > Sure, but I think we need some evidence that these tests are unreliable first, and if the tests are unreliable then they should be onto the problem list so that they aren't run. -Alan. From gary.adams at oracle.com Wed Nov 16 17:43:34 2011 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Nov 2011 12:43:34 -0500 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3F2F0.2020408@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> <4EC3F2F0.2020408@oracle.com> Message-ID: <4EC3F646.9040909@oracle.com> On 11/16/11 12:29 PM, Alan Bateman wrote: > On 16/11/2011 17:21, Kelly O'Hair wrote: >> : >> >> But if the test naturally runs long enough, any win from using samevm for >> that particular testcase is kind of minimal. >> And if using samevm makes the test less reliable or makes the other tests >> sharing it's crib less reliable, >> then I have no issue giving these babies their own cribs. ;^) >> > Sure, but I think we need some evidence that these tests are unreliable first, > and if the tests are unreliable then they should be onto the problem list so > that they aren't run. > > -Alan. Agreed! I intend to do a full linux/arm jtreg run with a local beagleBoard cranked down to 300 MHz. Sounds like I should test the default and samevm mode. I'll start with a jdk7 embedded image to get a baseline. From Alan.Bateman at oracle.com Wed Nov 16 18:09:54 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2011 18:09:54 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3F646.9040909@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> <4EC3F2F0.2020408@oracle.com> <4EC3F646.9040909@oracle.com> Message-ID: <4EC3FC72.9020709@oracle.com> On 16/11/2011 17:43, Gary Adams wrote: > > Agreed! > > I intend to do a full linux/arm jtreg > run with a local beagleBoard cranked down > to 300 MHz. Sounds like I should test > the default and samevm mode. > > I'll start with a jdk7 embedded image > to get a baseline. It's not currently possible to specify the top level test directory and run all tests in samevm or agentvm mode. I don't think it's possible to run the AWT tests in samevm mode for example. If you look at jdk/test/Makefile then you'll see which areas can run in agentvm (or samevm) mode. It's something that I was chatting with Jon about recently and he pointed me to a patch from Mark Wielaard [1] that whitelists directories of tests that can run in samevm mode. I think Jon is hoping to integrate this, maybe extending it to work with the newer agent vm mode. -Alan [1] http://mail.openjdk.java.net/pipermail/jtreg-use/2008-November/000048.html From kumar.x.srinivasan at oracle.com Wed Nov 16 21:07:55 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 16 Nov 2011 21:07:55 +0000 Subject: hg: jdk8/tl/jdk: 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Message-ID: <20111116210812.E9E9F47393@hg.openjdk.java.net> Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/398442b00b2b 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Reviewed-by: ohair, katleman ! make/docs/Makefile From chris.hegarty at oracle.com Wed Nov 16 23:23:38 2011 From: chris.hegarty at oracle.com (chris hegarty) Date: Wed, 16 Nov 2011 23:23:38 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3FC72.9020709@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC3EB3C.3000608@oracle.com> <4EC3F2F0.2020408@oracle.com> <4EC3F646.9040909@oracle.com> <4EC3FC72.9020709@oracle.com> Message-ID: <4EC445FA.2060302@oracle.com> On 16/11/2011 18:09, Alan Bateman wrote: > On 16/11/2011 17:43, Gary Adams wrote: >> >> Agreed! >> >> I intend to do a full linux/arm jtreg >> run with a local beagleBoard cranked down >> to 300 MHz. Sounds like I should test >> the default and samevm mode. >> >> I'll start with a jdk7 embedded image >> to get a baseline. The timeouts in the tests you mentioned are particularly small, I guess this is where the issue of reliability is coming from, right? If these timeouts (in some cases) are just catch all for bugs that used to deadlock, but no longer do (since they are now fixed). Would it make sense to just increase these timeouts in the tests themselves? -Chris. > It's not currently possible to specify the top level test directory and > run all tests in samevm or agentvm mode. I don't think it's possible to > run the AWT tests in samevm mode for example. If you look at > jdk/test/Makefile then you'll see which areas can run in agentvm (or > samevm) mode. It's something that I was chatting with Jon about recently > and he pointed me to a patch from Mark Wielaard [1] that whitelists > directories of tests that can run in samevm mode. I think Jon is hoping > to integrate this, maybe extending it to work with the newer agent vm mode. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/jtreg-use/2008-November/000048.html From david.holmes at oracle.com Thu Nov 17 04:43:13 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2011 14:43:13 +1000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC3E4EE.5060902@oracle.com> References: <4EC3E4EE.5060902@oracle.com> Message-ID: <4EC490E1.2080409@oracle.com> Gary, On 17/11/2011 2:29 AM, Gary Adams wrote: > > The jtreg tests that use othervm along with a timeout argument should be > fairly reliable in getting a consistent result. The tests that did not > specify > othervm may run into problems, if they are run concurrently with other > tests. Given they are not run concurrently with other tests (modulo the testing framework [gtee/ute not jtreg] running multiple testsuites on the same machine) the only issue I can see that would impact samevm mode is if other test lefts threads behind. I'm not sure if this is possible with jtreg, but if it were then it is those other tests that need to be fixed. As Alan indicated we want to reduce use of othervm where we can because often the overhead of launching a new VM far outweighs the execution time of a successful test. David ----- > Here's a quick sampling of the java/util and java/lang tests that might > have issues. > Would there be any harm in changing these to designate running in > othervm mode? > > find jdk/test/java/{util,lang} -type f |grep -v hg/|xargs grep -n @run > |grep timeout |egrep -v "othervm|shell" > > jdk/test/java/util/ResourceBundle/Bug4168625Test.java:27: @run > main/timeout=600 Bug4168625Test > jdk/test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java:38: > * @run main/timeout=7000 CancelledProducerConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java:38: > * @run main/timeout=3600 MultipleProducersSingleConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java:38: > * @run main/timeout=3600 ProducerConsumerLoops > jdk/test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java:38: > * @run main/timeout=600 SingleProducerMultipleConsumerLoops > jdk/test/java/util/concurrent/ConcurrentHashMap/MapCheck.java:38: * @run > main/timeout=240 MapCheck > jdk/test/java/util/concurrent/ConcurrentHashMap/MapLoops.java:38: * @run > main/timeout=1600 MapLoops > jdk/test/java/util/concurrent/Exchanger/ExchangeLoops.java:38: * @run > main/timeout=720 ExchangeLoops > jdk/test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java:38: > * @run main/timeout=3600 ExecutorCompletionServiceLoops > jdk/test/java/util/concurrent/FutureTask/CancelledFutureLoops.java:38: * > @run main/timeout=2000 CancelledFutureLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java:38: > * @run main/timeout=2800 CancelledLockLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/LockOncePerThreadLoops.java:38: > * @run main/timeout=15000 LockOncePerThreadLoops > jdk/test/java/util/concurrent/locks/ReentrantLock/SimpleReentrantLockLoops.java:38: > * @run main/timeout=4500 SimpleReentrantLockLoops > jdk/test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java:38: > * @run main/timeout=4700 MapLoops > jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run > main/timeout=15 LoggingDeadlock > jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run > main/timeout=15 LoggingDeadlock2 > jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run > main/timeout=80 LoggingDeadlock3 > jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run > main/timeout=15 LoggingDeadlock4 > jdk/test/java/util/zip/ZipFile/ManyEntries.java:27: * @run > main/timeout=600 ManyEntries > jdk/test/java/lang/annotation/AnnotationTypeMismatchException/FoundType.java:29: > * @run main/timeout=30 FoundType > jdk/test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java:34: > * @run main/timeout=300 CollectionUsageThreshold > From Alan.Bateman at oracle.com Thu Nov 17 08:29:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2011 08:29:33 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC490E1.2080409@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> Message-ID: <4EC4C5ED.2070207@oracle.com> On 17/11/2011 04:43, David Holmes wrote: > > Given they are not run concurrently with other tests (modulo the > testing framework [gtee/ute not jtreg] running multiple testsuites on > the same machine) the only issue I can see that would impact samevm > mode is if other test lefts threads behind. I'm not sure if this is > possible with jtreg, but if it were then it is those other tests that > need to be fixed. When jtreg runs tests in samevm or agentvm mode then it creates a thread group for the test. When the test completes then it attempts "cleanup" that I think includes interrupting any remaining non-daemon threads in the group. I think there retry logic in there and eventually it gives up causing the test to fail (in error). There are other checks to help us catch tests that don't clean-up, the main one we used to be (until we fixed the tests) that they left files open. As you mention threads then I should mention that I was looking recently into why the tests were taking a long time to run on some systems and found a couple of tests that leave daemon threads behind. Here's two where tests were leaving spinning threads behind: http://bugs.sun.com/view_bug.do?bug_id=7094842 http://bugs.sun.com/view_bug.do?bug_id=7094995 Max fixed the first one promptly, I've been meaning to nab Neil about the second one. > > As Alan indicated we want to reduce use of othervm where we can > because often the overhead of launching a new VM far outweighs the > execution time of a successful test. Right although we have our share of tests that take several seconds (and more) to run. I see Chris's mail points out that some tests do have an unusually small timeout. For those tests then I would be tempted to just remove the timeout. Most likely the original author of the test put a small timeout to make it quick to test on a JDK that didn't have the fix. -Alan. From chris.hegarty at oracle.com Thu Nov 17 09:14:10 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Nov 2011 09:14:10 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC4C5ED.2070207@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> Message-ID: <4EC4D062.8060102@oracle.com> On 17/11/2011 08:29, Alan Bateman wrote: > ..... > > I see Chris's mail points out that some tests do have an unusually small > timeout. For those tests then I would be tempted to just remove the > timeout. Most likely the original author of the test put a small timeout > to make it quick to test on a JDK that didn't have the fix. Right, I've seen this before ( bug in JDK that causes deadlock, set small timeout on test so doesn't block for too long before being interrupted by jtreg). But if these tests ever fail then it means we have a problem, the small timeout is just not necessary at all in a JDK that doesn't have the issue being tested for. Maybe this would be a good place to start and eliminate some of the low hanging fruit ;-) -Chris. > > -Alan. > From gary.adams at oracle.com Thu Nov 17 11:22:44 2011 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 17 Nov 2011 06:22:44 -0500 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC4D062.8060102@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> Message-ID: <4EC4EE84.5040706@oracle.com> On 11/17/11 4:14 AM, Chris Hegarty wrote: > On 17/11/2011 08:29, Alan Bateman wrote: >> ..... >> >> I see Chris's mail points out that some tests do have an unusually small >> timeout. For those tests then I would be tempted to just remove the >> timeout. Most likely the original author of the test put a small timeout >> to make it quick to test on a JDK that didn't have the fix. > > Right, I've seen this before ( bug in JDK that causes deadlock, set > small timeout on test so doesn't block for too long before being > interrupted by jtreg). But if these tests ever fail then it means we > have a problem, the small timeout is just not necessary at all in a > JDK that doesn't have the issue being tested for. > > Maybe this would be a good place to start and eliminate some of the > low hanging fruit ;-) It would help to know which of the quick timeouts were intentional and which ones are required for proper execution of the tests. Not all "drops" are good for "applesauce". From chris.hegarty at oracle.com Thu Nov 17 11:36:03 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 17 Nov 2011 11:36:03 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC4EE84.5040706@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> <4EC4EE84.5040706@oracle.com> Message-ID: <4EC4F1A3.1010902@oracle.com> On 17/11/2011 11:22, Gary Adams wrote: > On 11/17/11 4:14 AM, Chris Hegarty wrote: >> On 17/11/2011 08:29, Alan Bateman wrote: >>> ..... >>> >>> I see Chris's mail points out that some tests do have an unusually small >>> timeout. For those tests then I would be tempted to just remove the >>> timeout. Most likely the original author of the test put a small timeout >>> to make it quick to test on a JDK that didn't have the fix. >> >> Right, I've seen this before ( bug in JDK that causes deadlock, set >> small timeout on test so doesn't block for too long before being >> interrupted by jtreg). But if these tests ever fail then it means we >> have a problem, the small timeout is just not necessary at all in a >> JDK that doesn't have the issue being tested for. >> >> Maybe this would be a good place to start and eliminate some of the >> low hanging fruit ;-) > It would help to know which of the quick timeouts > were intentional and which ones are required for > proper execution of the tests. Unfortunately, with most of these intermittent failures there is no silver bullet, each test may have to be looked at individually. We've been going through this process for months now :-( From the original list you sent out the obvious candidates for removal of the timeout parameter are: jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run main/timeout=15 LoggingDeadlock jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run main/timeout=15 LoggingDeadlock2 jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run main/timeout=80 LoggingDeadlock3 jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run main/timeout=15 LoggingDeadlock4 If these tests ever encounter a java level deadlock and need to be interrupted by the jtreg harness, then there is a JDK implementation bug that needs to be fixed. It looks like these timeouts were added when developing the original bug fix ( and test ) so the test times out in a timely manner when running a JDK without the fix. This is not needed for correct operation of the test itself. Are you seeing issues with these test when running embedded on slow hardware? -Chris. > > Not all "drops" are good for "applesauce". From gary.adams at oracle.com Thu Nov 17 12:35:18 2011 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 17 Nov 2011 07:35:18 -0500 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC4F1A3.1010902@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> <4EC4EE84.5040706@oracle.com> <4EC4F1A3.1010902@oracle.com> Message-ID: <4EC4FF86.9050102@oracle.com> On 11/17/11 6:36 AM, Chris Hegarty wrote: > On 17/11/2011 11:22, Gary Adams wrote: >> On 11/17/11 4:14 AM, Chris Hegarty wrote: >>> On 17/11/2011 08:29, Alan Bateman wrote: >>>> ..... >>>> >>>> I see Chris's mail points out that some tests do have an unusually >>>> small >>>> timeout. For those tests then I would be tempted to just remove the >>>> timeout. Most likely the original author of the test put a small >>>> timeout >>>> to make it quick to test on a JDK that didn't have the fix. >>> >>> Right, I've seen this before ( bug in JDK that causes deadlock, set >>> small timeout on test so doesn't block for too long before being >>> interrupted by jtreg). But if these tests ever fail then it means we >>> have a problem, the small timeout is just not necessary at all in a >>> JDK that doesn't have the issue being tested for. >>> >>> Maybe this would be a good place to start and eliminate some of the >>> low hanging fruit ;-) >> It would help to know which of the quick timeouts >> were intentional and which ones are required for >> proper execution of the tests. > > Unfortunately, with most of these intermittent failures there is no > silver bullet, each test may have to be looked at individually. We've > been going through this process for months now :-( > > From the original list you sent out the obvious candidates for removal > of the timeout parameter are: > > jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run > main/timeout=15 LoggingDeadlock > jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run > main/timeout=15 LoggingDeadlock2 > jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run > main/timeout=80 LoggingDeadlock3 > jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run > main/timeout=15 LoggingDeadlock4 Can we confirm with the test author if the timeouts could be removed? > > If these tests ever encounter a java level deadlock and need to be > interrupted by the jtreg harness, then there is a JDK implementation > bug that needs to be fixed. It looks like these timeouts were added > when developing the original bug fix ( and test ) so the test times > out in a timely manner when running a JDK without the fix. This is not > needed for correct operation of the test itself. > > Are you seeing issues with these test when running embedded on slow > hardware? I haven't had the cycles to get to the test run on embedded hardware, but I may get to it today. > > -Chris. > >> >> Not all "drops" are good for "applesauce". From gary.adams at oracle.com Thu Nov 17 20:28:37 2011 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 17 Nov 2011 15:28:37 -0500 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC312D8.4060406@oracle.com> References: <4EC2C818.2060201@oracle.com> <4EC312D8.4060406@oracle.com> Message-ID: <4EC56E75.2020504@oracle.com> Here's my first concrete slow machine timed out test ... jdk/test/java/lang/concurrent/forkjoin/Integrate.java I had been looking at tests that had a declared "timeout=xxx", but today I just started running the java/util/concurrent tests at a variety of clock speeds using ejdk1.7.0 and found a test that passes when running at 600MHz and timed out at 300Mhz. The test passes at 300 MHz if I include "-timeout:2" on the jtreg command line. At 600Mhz the test runs for 84 seconds (under the default 120 second timeout). At 300Mhz the test runs for 168 seconds. Since this test does not do an internal wait or delay operation passing in a timeout factor would not help in this case. In general it seems that tests that declare a timeout less than 120 seconds are indicating that an early termination for the test is acceptable. Tests declaring a longer than 120 second timeout recognize that additional processing time may be required. I'll try a longer overnight run at 300MHz to see if I can catch some other tests that are close to the 120 second threshold. ... On 11/15/11 08:33 PM, David Holmes wrote: > Hi Gary, > > On 16/11/2011 6:14 AM, Gary Adams wrote: >> I've been scanning a number of the slow machine test >> bugs that are reported and wanted to check to see if >> anyone has looked into time dependencies in the regression >> tests previously. From what I've been able to learn so far >> individual bugs can use the "timeout" parameter to indicate to >> the test harness an expected time to run. >> >> The test harness has command line arguments where it can >> filter out tests that take too long (timelimit) or can apply a >> multiplier to >> to the timeout when conditions are known to slow down the process >> (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp >> >> I see that there are some wrappers that can be applied around running >> a particular test to allow processing before main(). Could this mechanism >> be exploited so the harness command line options could be made known >> to the time dependent tests as command line arguments or as system >> properties? >> >> My thought is the current timeout granularity is too large and only applies >> to the full test execution. If a test knew that a timeoutFactor was to >> be applied, >> it could internally adjust the time dependent delays appropriately. e.g. >> not every sleep(), await(), join() with timeouts would need the >> timeoutFactor applied. > > I don't quite get what you mean about the timeouts applied to sleeps, awaits > etc. Depending on the test some of these are delays (eg sleep is usually used > this way) because it may not be feasible (or even possible) to coordinate the > threads directly; while others (await, wait etc) are actual timeouts - if they > expire it is an error because something appears to have gone wrong somewhere > (of course this can be wrong because the timeout was too short for a given > situation). > > As many of these tests have evolved along with the testing infrastructure it > isn't always very clear who has responsibility for programming defensive > timeouts. And many tests are designed to be run stand-alone or under a test > harness, where exceptions due to timeouts are preferable to hangs. > > Further, while we can add a scale factor for known retarding factors - like > Xcomp - there's no general way to assess the target machine capability (# > cores, speed) and load, as it may impact a given test. And historically there > has been a lack of resources to investigate and solve these issues. > > Cheers, > David > >> Before any test could be updated the information would need to be available >> from the test context. >> >> Any feedback/pointers appreciated! >> >> >> See >> timeoutFactorArg >> jtreg/src/share/classes/com/sun/javatest/regtest/Main.java >> runOtherJVM() >> jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java >> maxTimeoutValue >> jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java >> >> From Alan.Bateman at oracle.com Thu Nov 17 23:16:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Nov 2011 23:16:51 +0000 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC56E75.2020504@oracle.com> References: <4EC2C818.2060201@oracle.com> <4EC312D8.4060406@oracle.com> <4EC56E75.2020504@oracle.com> Message-ID: <4EC595E3.5080809@oracle.com> On 17/11/2011 20:28, Gary Adams wrote: > : > > In general it seems that tests that declare a timeout less than 120 > seconds are indicating that an early termination for the test is > acceptable. > Tests declaring a longer than 120 second timeout recognize that > additional > processing time may be required. I can't think of any need for tests to specify a timeout less then the default. When fixing a deadlock or some such bug then you will typically run the test with a JDK build that doesn't have the fix and a JDK build with the fix. When testing with the former then it's nice to have the test timeout quickly which is why some tests do have a short timeout. But since the bugs are long fixed then these tests should not hang or deadlock and so the default timeout should be fine. Clearly slower/stress tests that have the potential to excess the default timeout need to override the default timeout. In any case, for 300Mhz then I would definitely run with -timeoutFactor:2 or greater. A useful file to look at is JTreport/text/timeStats.txt as it shows the distribution of the test execution times. -Alan From mandy.chung at oracle.com Thu Nov 17 23:48:10 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 17 Nov 2011 23:48:10 +0000 Subject: hg: jdk8/tl/jdk: 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Message-ID: <20111117234828.14214473BD@hg.openjdk.java.net> Changeset: 3cd7dcf4a302 Author: mchung Date: 2011-11-17 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cd7dcf4a302 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung Contributed-by: gary.adams at oracle.com ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java From david.holmes at oracle.com Fri Nov 18 01:12:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Nov 2011 11:12:18 +1000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC4F1A3.1010902@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> <4EC4EE84.5040706@oracle.com> <4EC4F1A3.1010902@oracle.com> Message-ID: <4EC5B0F2.70002@oracle.com> Chris, On 17/11/2011 9:36 PM, Chris Hegarty wrote: > From the original list you sent out the obvious candidates for removal > of the timeout parameter are: > > jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run > main/timeout=15 LoggingDeadlock > jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run > main/timeout=15 LoggingDeadlock2 > jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run > main/timeout=80 LoggingDeadlock3 > jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run > main/timeout=15 LoggingDeadlock4 > > If these tests ever encounter a java level deadlock and need to be > interrupted by the jtreg harness, then there is a JDK implementation bug > that needs to be fixed. Many tests that would hang if they encountered the problem they are testing for, use timeouts as a means to not lock up the entire testing process. We should not be removing such timeouts in my view, even if we have to adjust them for slower machines etc. David ----- It looks like these timeouts were added when > developing the original bug fix ( and test ) so the test times out in a > timely manner when running a JDK without the fix. This is not needed for > correct operation of the test itself. > > Are you seeing issues with these test when running embedded on slow > hardware? > > -Chris. > >> >> Not all "drops" are good for "applesauce". From david.holmes at oracle.com Fri Nov 18 01:58:20 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Nov 2011 11:58:20 +1000 Subject: Passing time factor to tests run under jtreg In-Reply-To: <4EC56E75.2020504@oracle.com> References: <4EC2C818.2060201@oracle.com> <4EC312D8.4060406@oracle.com> <4EC56E75.2020504@oracle.com> Message-ID: <4EC5BBBC.9090407@oracle.com> Gary, On 18/11/2011 6:28 AM, Gary Adams wrote: > Here's my first concrete slow machine timed out test ... > jdk/test/java/lang/concurrent/forkjoin/Integrate.java > > I had been looking at tests that had a declared "timeout=xxx", > but today I just started running the java/util/concurrent > tests at a variety of clock speeds using ejdk1.7.0 and > found a test that passes when running at 600MHz and > timed out at 300Mhz. The test passes at 300 MHz if I > include "-timeout:2" on the jtreg command line. I think I have been misunderstanding the point you've been trying to make here. I'm not sure there is a simple relationship here with the use of internal delays/timeouts in a test. delays (wait long enough til XXX should have happened) would seem to need to be scaled under the same considerations as used for -timeout. Internal timeouts (give up after XXX time units because something seems to have gone wrong) on the other hand are typically much coarser/larger and so already accommodate a range of -timeout values implicitly. The scaling factor need to come from the environment launching the test, but the tests need to be modified to use it. > At 600Mhz the test runs for 84 seconds (under the default > 120 second timeout). At 300Mhz the test runs for 168 > seconds. > > Since this test does not do an internal wait or delay operation > passing in a timeout factor would not help in this case. > > In general it seems that tests that declare a timeout less than 120 > seconds are indicating that an early termination for the test is > acceptable. I agree with Alan that it doesn't make sense to specify timeouts less than the default. > Tests declaring a longer than 120 second timeout recognize that additional > processing time may be required. Most likely the test failed somewhere sometime and bumping the timeout fixed it. wash-rinse-repeat Cheers, David > I'll try a longer overnight run at 300MHz to see if I can catch some > other tests that are close to the 120 second threshold. > > ... > > > On 11/15/11 08:33 PM, David Holmes wrote: >> Hi Gary, >> >> On 16/11/2011 6:14 AM, Gary Adams wrote: >>> I've been scanning a number of the slow machine test >>> bugs that are reported and wanted to check to see if >>> anyone has looked into time dependencies in the regression >>> tests previously. From what I've been able to learn so far >>> individual bugs can use the "timeout" parameter to indicate to >>> the test harness an expected time to run. >>> >>> The test harness has command line arguments where it can >>> filter out tests that take too long (timelimit) or can apply a >>> multiplier to >>> to the timeout when conditions are known to slow down the process >>> (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp >>> >>> I see that there are some wrappers that can be applied around running >>> a particular test to allow processing before main(). Could this >>> mechanism >>> be exploited so the harness command line options could be made known >>> to the time dependent tests as command line arguments or as system >>> properties? >>> >>> My thought is the current timeout granularity is too large and only >>> applies >>> to the full test execution. If a test knew that a timeoutFactor was to >>> be applied, >>> it could internally adjust the time dependent delays appropriately. e.g. >>> not every sleep(), await(), join() with timeouts would need the >>> timeoutFactor applied. >> >> I don't quite get what you mean about the timeouts applied to sleeps, >> awaits etc. Depending on the test some of these are delays (eg sleep >> is usually used this way) because it may not be feasible (or even >> possible) to coordinate the threads directly; while others (await, >> wait etc) are actual timeouts - if they expire it is an error because >> something appears to have gone wrong somewhere (of course this can be >> wrong because the timeout was too short for a given situation). >> >> As many of these tests have evolved along with the testing >> infrastructure it isn't always very clear who has responsibility for >> programming defensive timeouts. And many tests are designed to be run >> stand-alone or under a test harness, where exceptions due to timeouts >> are preferable to hangs. >> >> Further, while we can add a scale factor for known retarding factors - >> like Xcomp - there's no general way to assess the target machine >> capability (# cores, speed) and load, as it may impact a given test. >> And historically there has been a lack of resources to investigate and >> solve these issues. >> >> Cheers, >> David >> >>> Before any test could be updated the information would need to be >>> available >>> from the test context. >>> >>> Any feedback/pointers appreciated! >>> >>> >>> See >>> timeoutFactorArg >>> jtreg/src/share/classes/com/sun/javatest/regtest/Main.java >>> runOtherJVM() >>> jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java >>> maxTimeoutValue >>> jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java >>> >>> >>> > From david.holmes at oracle.com Fri Nov 18 02:02:18 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Nov 2011 12:02:18 +1000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC5B0F2.70002@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> <4EC4EE84.5040706@oracle.com> <4EC4F1A3.1010902@oracle.com> <4EC5B0F2.70002@oracle.com> Message-ID: <4EC5BCAA.2070604@oracle.com> On 18/11/2011 11:12 AM, David Holmes wrote: > Chris, > > On 17/11/2011 9:36 PM, Chris Hegarty wrote: >> From the original list you sent out the obvious candidates for removal >> of the timeout parameter are: >> >> jdk/test/java/util/logging/LoggingDeadlock.java:32: * @run >> main/timeout=15 LoggingDeadlock >> jdk/test/java/util/logging/LoggingDeadlock2.java:31: * @run >> main/timeout=15 LoggingDeadlock2 >> jdk/test/java/util/logging/LoggingDeadlock3.java:30: * @run >> main/timeout=80 LoggingDeadlock3 >> jdk/test/java/util/logging/LoggingDeadlock4.java:30: * @run >> main/timeout=15 LoggingDeadlock4 >> >> If these tests ever encounter a java level deadlock and need to be >> interrupted by the jtreg harness, then there is a JDK implementation bug >> that needs to be fixed. > > Many tests that would hang if they encountered the problem they are > testing for, use timeouts as a means to not lock up the entire testing > process. We should not be removing such timeouts in my view, even if we > have to adjust them for slower machines etc. Okay based on discussion in other thread - if the above timeouts are smaller than the default then perhaps they should be removed. Though where does this default come from? If we remove explicit timeouts and the default gets lowered then we may get a sudden set of failures. Too many pieces here under different control. David > David > ----- > > It looks like these timeouts were added when >> developing the original bug fix ( and test ) so the test times out in a >> timely manner when running a JDK without the fix. This is not needed for >> correct operation of the test itself. >> >> Are you seeing issues with these test when running embedded on slow >> hardware? >> >> -Chris. >> >>> >>> Not all "drops" are good for "applesauce". From mandy.chung at oracle.com Fri Nov 18 03:14:08 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 17 Nov 2011 19:14:08 -0800 Subject: Garbage collection race condition before final checks In-Reply-To: <4EC2AD59.9070407@oracle.com> References: <4EB3EA75.2050006@oracle.com> <4EB8016E.2050100@oracle.com> <4EB82351.9020001@oracle.com> <4CEB4B9D-B219-4908-A1D8-D267016D68E3@oracle.com> <4EB85F89.7050601@oracle.com> <4EB8F057.1080905@oracle.com> <4EB94C38.5030104@oracle.com> <4EB9FDCF.9020909@oracle.com> <4EBBE286.10109@oracle.com> <4EC25A58.6030601@oracle.com> <4EC2A7FF.4010708@oracle.com> <4EC2AD59.9070407@oracle.com> Message-ID: <4EC5CD80.4030401@oracle.com> On 11/15/11 10:20 AM, Gary Adams wrote: >>> Added PlatformLoggingMXBeanTest to the 7067691 bug fix, >>> e.g. instance variables for Logger variables to prevent premature >>> weak reference collection. >>> >>> http://cr.openjdk.java.net/~gadams/7067691/ >> Gary, I have pushed your changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cd7dcf4a302 Mandy From Alan.Bateman at oracle.com Fri Nov 18 07:02:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Nov 2011 07:02:09 +0000 Subject: Potential timeout issues - tests running in the same vm In-Reply-To: <4EC5BCAA.2070604@oracle.com> References: <4EC3E4EE.5060902@oracle.com> <4EC490E1.2080409@oracle.com> <4EC4C5ED.2070207@oracle.com> <4EC4D062.8060102@oracle.com> <4EC4EE84.5040706@oracle.com> <4EC4F1A3.1010902@oracle.com> <4EC5B0F2.70002@oracle.com> <4EC5BCAA.2070604@oracle.com> Message-ID: <4EC602F1.4090906@oracle.com> On 18/11/2011 02:02, David Holmes wrote: > > Okay based on discussion in other thread - if the above timeouts are > smaller than the default then perhaps they should be removed. Though > where does this default come from? If we remove explicit timeouts and > the default gets lowered then we may get a sudden set of failures. The default timeout is specified in the tag spec [1] so is unlikely to change. -Alan. [1] http://openjdk.java.net/jtreg/tag-spec.txt From weijun.wang at oracle.com Fri Nov 18 08:14:34 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 18 Nov 2011 08:14:34 +0000 Subject: hg: jdk8/tl/jdk: 7077172: KerberosTime does not take into account system clock adjustement Message-ID: <20111118081452.A6274473CF@hg.openjdk.java.net> Changeset: 5bfff9616b86 Author: weijun Date: 2011-11-18 16:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bfff9616b86 7077172: KerberosTime does not take into account system clock adjustement Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/KerberosTime.java From martin.desruisseaux at geomatys.fr Fri Nov 18 14:29:38 2011 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Fri, 18 Nov 2011 15:29:38 +0100 Subject: StrictMath performance improvement not ported to Math? Message-ID: <4EC66BD2.5050205@geomatys.fr> Hello all On December 1, 2010, "darcy" committed a slight performance improvement to the StrictMath.min/max methods with floating point arguments (commit 8aabca72877c). The calls to the doubleToLongBits(double) method were replaced by calls to the doubleToRawLongBits(double) method, and similarly for the float type. Since the call to doubleToLongBits was used only in order to determine if an argument was negative zero, and since NaN can not map to the bits pattern of -0.0, the extra cost of collapsing all NaN values to a single canonical NaN (which is the only difference between doubleToLongBits and doubleToRawLongBits) was unnecessary. However this improvement has not been ported from StrictMath to Math; the more widely-used Math class still invokes the (presumed) slower doubleToLongBits(double) method. Actually it appears that most Math / StrictMath method implementations delegate to the other class: some Math methods delegates to StrictMath (mostly the methods backed by native code), and some StrictMath methods delegate to Math (mostly the methods implemented in pure-Java). The min/max methods are an exception; their implementation is copied in both classes. Maybe this explain why the code was updated in only one class and not the other? In the patch submitted below, I propose the following changes: 1) Ported the doubleToLongBits --> doubleToRawLongBits changes from StrictMath to Math. 2) Replaced StrictMath implementations by calls to Math, in order to reduce the risk that the code of only one class is updated in the future. 3) In if statements, replaced: (a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits) by (Double.doubleToLongBits(a) == negativeZeroDoubleBits) since the later implies the former. 4) Moved the check for (a != a) from the method beginning to the last statement, which is tested only if (a <= b) were false rather than tested unconditionally in every cases. I'm not sure if it make a real performance difference however. Webrev link: http://webrev.geomatys.com/Math/min_max/index.html Regards, Martin From gary.adams at oracle.com Fri Nov 18 16:33:32 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 18 Nov 2011 11:33:32 -0500 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Message-ID: <4EC688DC.9070407@oracle.com> I think this change is ready to commit, just need a sponsor for the last push (Mandy/David?). http://cr.openjdk.java.net/~gadams/6731620/ From gary.adams at oracle.com Fri Nov 18 16:46:35 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 18 Nov 2011 11:46:35 -0500 Subject: Code Review - 6818464 TEST_BUG: Timeout values in several java/util tests are insufficient Message-ID: <4EC68BEB.50609@oracle.com> I think this change is ready to commit, just need a sponsor for the last push (Mandy/David?). http://cr.openjdk.java.net/~gadams/6818464/ From gary.adams at oracle.com Fri Nov 18 16:51:34 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 18 Nov 2011 11:51:34 -0500 Subject: Code Review - 6860309 TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Message-ID: <4EC68D16.4010002@oracle.com> I think this change is ready to commit, just need a sponsor for the last push (Mandy/David?). http://cr.openjdk.java.net/~gadams/6860309/ From dalibor.topic at oracle.com Fri Nov 18 16:58:24 2011 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 18 Nov 2011 17:58:24 +0100 Subject: StrictMath performance improvement not ported to Math? In-Reply-To: <4EC66BD2.5050205@geomatys.fr> References: <4EC66BD2.5050205@geomatys.fr> Message-ID: <4EC68EB0.1000403@oracle.com> On 11/18/11 3:29 PM, Martin Desruisseaux wrote: > Hello all > > On December 1, 2010, "darcy" committed You probably know this already, but I just wanted to point out that one can use the census page as a handy decoder ring for committer names: http://openjdk.java.net/census#darcy cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From gary.adams at oracle.com Fri Nov 18 17:03:45 2011 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 18 Nov 2011 12:03:45 -0500 Subject: Code Review - 7084033 TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Message-ID: <4EC68FF1.70406@oracle.com> I think this change is ready to commit, just need a sponsor for the last push (Mandy/David?). http://cr.openjdk.java.net/~gadams/7084033/ From darryl.mocek at oracle.com Fri Nov 18 18:27:53 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 18 Nov 2011 10:27:53 -0800 Subject: Code Review Request for Bug #5035850 Message-ID: <4EC6A3A9.3000603@oracle.com> Hello. Please review this patch to fix a serialization issue with String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize the class, the equals test will fail in the comparison of what was serialized with what was deserialized. Webrev, including test, can be found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev Thanks, Darryl From jeffhain at rocketmail.com Fri Nov 18 19:35:16 2011 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 18 Nov 2011 19:35:16 +0000 (GMT) Subject: what is the most precise time I can get in JDK? In-Reply-To: <4EC36FB2.80508@oracle.com> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> <4EC36FB2.80508@oracle.com> Message-ID: <1321644916.99252.YahooMailNeo@web29206.mail.ird.yahoo.com> Hi. I've had the same need (or desire), and made a ThinTime class for it (attached). Returned time : - is not much more inaccurate than System.currentTimeMillis(), - is always ahead of System.currentTimeMillis(), - is monotonic (unless System.currentTimeMillis() jumps backward), - should change way more often than System.currentTimeMillis(). NB: It makes use of "raw" AtomicXXX classes, without cache line padding, so there is room for optimization here, but maybe you are like me and prefer to wait on @Contended annotation arrival than plague your code with unreliable padding magic :) -Jeff ________________________________ De?: Weijun Wang ??: David Holmes Cc?: core-libs-dev Envoy? le : Mercredi 16 Novembre 2011 9h09 Objet?: Re: what is the most precise time I can get in JDK? Hi Davis Yes, I know nanoTime() is precise, but how can I get a clock time from it? I have tried to record a currentTimeMillis() value when the program starts and then use the elapse of the nanaTime() to get a current time. This will break if the user adjusts the system clock during the program execution. One solution is to keep tracking the changing of both currentTimeMillis() and nanoTime(). If the change of one has a difference (say, > 1 sec) from the other one, it means a system clock change and I can quickly reset my time to currentTimeMillis(). Thanks Max On 11/16/2011 03:23 PM, David Holmes wrote: > Hi Max, > > On 16/11/2011 2:55 PM, Weijun Wang wrote: >> I need a precise time, and is currently using java.util.Date, which knows >> about milliseconds, but unfortunately the precision is only 10-15 >> milliseconds on a Windows. >> >> In fact, I don't really need it to be so correct. My requirements are: >> >> 1. It's enough correct, say, at least as correct as Date. >> 2. It's precise in a relative sense, i.e. it changes fast >> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >> system >> clock > > There are only two time source available: > > 1. The time-of-day clock > > This is what Date reports and is also what System.currentTimeMillis > reports. It only has millisecond precision. It's rate of update is > dependent on the OS - for Windows that is typically every 10ms or every > 15ms depending on version. > > 2. The high resolution time source > > This is what System.nanoTime reports. It has nanosecond precision, but > again depending on the OS it's resolution (update rate) will vary. The > update rate should easily be in the tens of microseconds. It should be > monotonic non-decreasing but it is not connected to the time-of-day > clock (and so should not be affected by any changes therein). > > I have an old blog entry on this: > > http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks > > David > ----- From Ulf.Zibis at gmx.de Fri Nov 18 19:45:23 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 18 Nov 2011 20:45:23 +0100 Subject: what is the most precise time I can get in JDK? In-Reply-To: <1321644916.99252.YahooMailNeo@web29206.mail.ird.yahoo.com> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> <4EC36FB2.80508@oracle.com> <1321644916.99252.YahooMailNeo@web29206.mail.ird.yahoo.com> Message-ID: <4EC6B5D3.5070501@gmx.de> Sounds interesting, but there is no attachment ? -Ulf Am 18.11.2011 20:35, schrieb Jeff Hain: > Hi. > > I've had the same need (or desire), and made a ThinTime class for it (attached). > > Returned time : > - is not much more inaccurate than System.currentTimeMillis(), > - is always ahead of System.currentTimeMillis(), > > - is monotonic (unless System.currentTimeMillis() jumps backward), > > - should change way more often than System.currentTimeMillis(). > > NB: It makes use of "raw" AtomicXXX classes, without cache line padding, > so there is room for optimization here, but maybe you are like me and > prefer to wait on @Contended annotation arrival than plague your code > with unreliable padding magic :) > > > -Jeff > > > ________________________________ > De : Weijun Wang > ? : David Holmes > Cc : core-libs-dev > Envoy? le : Mercredi 16 Novembre 2011 9h09 > Objet : Re: what is the most precise time I can get in JDK? > > Hi Davis > > Yes, I know nanoTime() is precise, but how can I get a clock time from > it? I have tried to record a currentTimeMillis() value when the program > starts and then use the elapse of the nanaTime() to get a current time. > This will break if the user adjusts the system clock during the program > execution. > > One solution is to keep tracking the changing of both > currentTimeMillis() and nanoTime(). If the change of one has a > difference (say,> 1 sec) from the other one, it means a system clock > change and I can quickly reset my time to currentTimeMillis(). > > Thanks > Max > > > > On 11/16/2011 03:23 PM, David Holmes wrote: >> Hi Max, >> >> On 16/11/2011 2:55 PM, Weijun Wang wrote: >>> I need a precise time, and is currently using java.util.Date, which knows >>> about milliseconds, but unfortunately the precision is only 10-15 >>> milliseconds on a Windows. >>> >>> In fact, I don't really need it to be so correct. My requirements are: >>> >>> 1. It's enough correct, say, at least as correct as Date. >>> 2. It's precise in a relative sense, i.e. it changes fast >>> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >>> system >>> clock >> There are only two time source available: >> >> 1. The time-of-day clock >> >> This is what Date reports and is also what System.currentTimeMillis >> reports. It only has millisecond precision. It's rate of update is >> dependent on the OS - for Windows that is typically every 10ms or every >> 15ms depending on version. >> >> 2. The high resolution time source >> >> This is what System.nanoTime reports. It has nanosecond precision, but >> again depending on the OS it's resolution (update rate) will vary. The >> update rate should easily be in the tens of microseconds. It should be >> monotonic non-decreasing but it is not connected to the time-of-day >> clock (and so should not be affected by any changes therein). >> >> I have an old blog entry on this: >> >> http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks >> >> David >> ----- From jeffhain at rocketmail.com Fri Nov 18 20:02:11 2011 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 18 Nov 2011 20:02:11 +0000 (GMT) Subject: what is the most precise time I can get in JDK? In-Reply-To: <4EC6B5D3.5070501@gmx.de> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> <4EC36FB2.80508@oracle.com> <1321644916.99252.YahooMailNeo@web29206.mail.ird.yahoo.com> <4EC6B5D3.5070501@gmx.de> Message-ID: <1321646531.16628.YahooMailNeo@web29212.mail.ird.yahoo.com> Weird, I'm almost sure I attached it (and sure I browsed to attach it). Maybe I clicked on it to look at it, and it removed it. I send again, with password toto (in case some security software removes attachments with .java files). -Jeff ________________________________ De?: Ulf Zibis ??: Jeff Hain Cc?: Weijun Wang ; core-libs-dev Envoy? le : Vendredi 18 Novembre 2011 20h45 Objet?: Re: Re : what is the most precise time I can get in JDK? Sounds interesting, but there is no attachment ? -Ulf Am 18.11.2011 20:35, schrieb Jeff Hain: > Hi. > > I've had the same need (or desire), and made a ThinTime class for it (attached). > > Returned time : > - is not much more inaccurate than System.currentTimeMillis(), > - is always ahead of System.currentTimeMillis(), > > - is monotonic (unless System.currentTimeMillis() jumps backward), > > - should change way more often than System.currentTimeMillis(). > > NB: It makes use of "raw" AtomicXXX classes, without cache line padding, > so there is room for optimization here, but maybe you are like me and > prefer to wait on @Contended annotation arrival than plague your code > with unreliable padding magic :) > > > -Jeff > > > ________________________________ >? De : Weijun Wang > ? : David Holmes > Cc : core-libs-dev > Envoy? le : Mercredi 16 Novembre 2011 9h09 > Objet : Re: what is the most precise time I can get in JDK? > > Hi Davis > > Yes, I know nanoTime() is precise, but how can I get a clock time from > it? I have tried to record a currentTimeMillis() value when the program > starts and then use the elapse of the nanaTime() to get a current time. > This will break if the user adjusts the system clock during the program > execution. > > One solution is to keep tracking the changing of both > currentTimeMillis() and nanoTime(). If the change of one has a > difference (say,>? 1 sec) from the other one, it means a system clock > change and I can quickly reset my time to currentTimeMillis(). > > Thanks > Max > > > > On 11/16/2011 03:23 PM, David Holmes wrote: >> Hi Max, >> >> On 16/11/2011 2:55 PM, Weijun Wang wrote: >>> I need a precise time, and is currently using java.util.Date, which knows >>> about milliseconds, but unfortunately the precision is only 10-15 >>> milliseconds on a Windows. >>> >>> In fact, I don't really need it to be so correct. My requirements are: >>> >>> 1. It's enough correct, say, at least as correct as Date. >>> 2. It's precise in a relative sense, i.e. it changes fast >>> 3. It should be monotonic, i.e. it grows, unless the user adjusts the >>> system >>> clock >> There are only two time source available: >> >> 1. The time-of-day clock >> >> This is what Date reports and is also what System.currentTimeMillis >> reports. It only has millisecond precision. It's rate of update is >> dependent on the OS - for Windows that is typically every 10ms or every >> 15ms depending on version. >> >> 2. The high resolution time source >> >> This is what System.nanoTime reports. It has nanosecond precision, but >> again depending on the OS it's resolution (update rate) will vary. The >> update rate should easily be in the tens of microseconds. It should be >> monotonic non-decreasing but it is not connected to the time-of-day >> clock (and so should not be affected by any changes therein). >> >> I have an old blog entry on this: >> >> http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks >> >> David >> ----- From jeffhain at rocketmail.com Fri Nov 18 20:13:09 2011 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 18 Nov 2011 20:13:09 +0000 (GMT) Subject: Tr : Re : what is the most precise time I can get in JDK? In-Reply-To: <1321646531.16628.YahooMailNeo@web29212.mail.ird.yahoo.com> References: <4EC3425A.6040805@oracle.com> <4EC364E6.50400@oracle.com> <4EC36FB2.80508@oracle.com> <1321644916.99252.YahooMailNeo@web29206.mail.ird.yahoo.com> <4EC6B5D3.5070501@gmx.de> <1321646531.16628.YahooMailNeo@web29212.mail.ird.yahoo.com> Message-ID: <1321647189.91522.YahooMailNeo@web29207.mail.ird.yahoo.com> New test with both attachments, and me as main destinatary (it did work when I sent it to myself _only_). In case it still fails, I copy-paste the whole code here (3 classes) (I hope it's not too large :). package thintime; import java.util.concurrent.atomic.AtomicLong; import java.util.concurrent.atomic.AtomicReference; /** ?* This class makes up in some ways to the absence of a ?* System.currentTimeNanos() method. If such a method ?* would get available, most of this class would become ?* pointless (unless the new method would be slower). ?* ?* Methods of this class are thread-safe and non-blocking. ?* ?* The advantage of methods of this class over ?* System.curentTimeMillis(), resides not in accuracy, ?* which is about the same,? but in that from a call to the next, ?* the returned value will change more often. ?* That's why it's called "ThinTime" and not "AccurateTime". ?* ?* The average current time computed is biased compared ?* to the time returned by System.currentTimeMillis(), ?* being usually a bit ahead of it, by an amount ?* depending on tolerance configuration. ?* ?* An offset can be defined, in milliseconds, relatively ?* to the value returned by System.currentTimeMillis(). ?* ?* Unless system time backward jumps, returned time ?* is never smaller than a previously returned time ?* (for a same method at least, since they do not ?* all have the same precision). ?* As a consequence, returned time gets stalled ?* once Long.MAX_VALUE nanoseconds time is reached, ?* unless actual system time does a backward jump. ?*/ public class ThinTime { ??? /* ???? * Note on using a time in nanoseconds, with a custom offset from system time. ???? * ???? * One year = 3600*24*365 seconds ???? * = 31_536_000 seconds ???? * = 31_536_000_000 milliseconds ???? * = 31_536_000_000_000_000 nanoseconds ???? * and ???? * (2^63)/31_536_000_000_000_000 = 292,47120867753601623541349568747 ???? * so with time in nanoseconds, starting from zero, a long allows to go up to 292 years, ???? * and starting from Long.MIN_VALUE, up to 584 years, which should be enough for most needs. ???? * ???? * Meanwhile, this class allows to define an offset relatively to system time, in milliseconds. ???? * It can therefore be used over a 584 years period of time located anywhere in the ???? * next 292 millions years, which should also be enough for most needs. ???? */ ??? /* ???? * System.currentTimeMillis() behavior illustration: ???? * time ???? *? ^ ???? *? |?????????? time = actual current time ???? *? |????????? / ???? *? |???????? / ???? * 9|??????? +-- time = System.currentTimeMillis() ???? * 8|?????? /| ???? * 7|????? +-+ (case 1: reaches actual current time) ???? * 6|???? /| | ???? * 5|??? / +-+ (case 2: does not reach actual current time) ???? * 4|?? /? | ???? * 3|? +---+ ???? * 2| /| ???? * 1|+-+ ???? * 0+-----------------------------------> actual current time ???? *? 0123456789 ???? * ???? * As shown, we consider the actual current time to always be ???? * superior or equal to the value returned by System.currentTimeMillis(). ???? * This might not be the case, but at worse it just introduces a ???? * small and constant bias in our measurement of time, which is no biggie ???? * since we just pretend to be "thin", and about as accurate (not more) ???? * than System.currentTimeMillis(). ???? * ???? * Let minSCTMJump be the min time jump when System.currentTimeMillis() ???? * returned value changes. ???? * minSCTMJump is estimated at first with a default value, then dynamically. ???? */ ??? //-------------------------------------------------------------------------- ??? // PUBLIC CLASSES ??? //-------------------------------------------------------------------------- ??? ??? public static class TimeRef { ??????? /** ???????? * Reference value returned by (System.currentTimeMillis() - systemTimeZeroMS). ???????? */ ??????? private final long refSCTM; ??????? /** ???????? * Reference value returned by System.nanoTime(). ???????? */ ??????? private final long refSNT; ??????? public TimeRef( ??????????????? long refSCTM, ??????????????? long refSNT) { ??????????? this.refSCTM = refSCTM; ??????????? this.refSNT = refSNT; ??????? } ??????? /** ???????? * @return Reference (System.currentTimeMillis() - systemTimeZeroMS). ???????? */ ??????? public long getRefSCTM() { ??????????? return this.refSCTM; ??????? } ??????? /** ???????? * @return Reference System.nanoTime(). ???????? */ ??????? public long getRefSNT() { ??????????? return this.refSNT; ??????? } ??? } ??? //-------------------------------------------------------------------------- ??? // MEMBERS ??? //-------------------------------------------------------------------------- ??? /** ???? * Max number of times sctm and snt are retrieved again, ???? * in case recently retrieved ones were not suited for ???? * time reference update. ???? */ ??? private static final int MAX_NBR_OF_TIME_REF_UPDATE_RE_ATTEMPTS = 3; ??? private static final String DEFAULT_FUTURE_TOLERANCE_RATIO_PROPERTY = "odk.thintime.ftr"; ??? private static final String DEFAULT_INITIAL_MIN_SCTM_JUMP_MS_PROPERTY = "odk.thintime.imsctmj"; ??? private static final String DEFAULT_SYSTEM_TIME_ZERO_MS_PROPERTY = "odk.thintime.stzero"; ??? ??? private static final double DEFAULT_FUTURE_TOLERANCE_RATIO; ??? static { ??????? String tmp = System.getProperty(DEFAULT_FUTURE_TOLERANCE_RATIO_PROPERTY); ??????? if (tmp != null) { ??????????? DEFAULT_FUTURE_TOLERANCE_RATIO = Double.parseDouble(tmp); ??????? } else { ??????????? DEFAULT_FUTURE_TOLERANCE_RATIO = 2.0; ??????? } ??? } ??? private static final long DEFAULT_INITIAL_MIN_SCTM_JUMP_MS; ??? static { ??????? String tmp = System.getProperty(DEFAULT_INITIAL_MIN_SCTM_JUMP_MS_PROPERTY); ??????? if (tmp != null) { ??????????? DEFAULT_INITIAL_MIN_SCTM_JUMP_MS = Long.parseLong(tmp); ??????? } else { ??????????? DEFAULT_INITIAL_MIN_SCTM_JUMP_MS = 100L; ??????? } ??? } ??? private static final long DEFAULT_SYSTEM_TIME_ZERO_MS; ??? static { ??????? String tmp = System.getProperty(DEFAULT_SYSTEM_TIME_ZERO_MS_PROPERTY); ??????? if (tmp != null) { ??????????? DEFAULT_SYSTEM_TIME_ZERO_MS = Long.parseLong(tmp); ??????? } else { ??????????? DEFAULT_SYSTEM_TIME_ZERO_MS = 0L; ??????? } ??? } ??? private static final ThinTime DEFAULT_INSTANCE = new ThinTime(); ??? ??? /** ???? * This ratio (>= 0.0) defines the maximum time delta into the future ???? * (the maximum time delta into the past is 0), ???? * from the time returned by System.currentTimeMillis(), to ???? * the "thin current time" (the time returned by methods of this class). ???? * ???? * This delta is computed as "ratio * minSCTMJump", where minSCTMJump ???? * is the min time jump when System.currentTimeMillis() value changes, ???? * i.e. System.currentTimeMillis()'s best precision (and hopefully accuracy). ???? * ???? * You want this ratio to be >= 1.0, or 0.0, considering ???? * what happens for values < 1.0: ???? * - If this ratio is 0.0, thin current time will always be equal ???? *?? to the time returned by System.currentTimeMillis(). ???? * - If this ratio is in ]0.0,1.0[, as thin current time will not be ???? *?? allowed to differ from System.currentTimeMillis() for more than ???? *?? System.currentTimeMillis()'s best accuracy, there will be a lot of ???? *?? recomputations of thin current time line (time references), ???? *?? which will also jump a lot relatively to the actual current time: ???? *?? this might be CPU heavy, and leads to a less thin/continuous ???? *?? time line. ???? * ???? * For ratios >= 1.0: ???? * - Since System.currentTimeMillis() can have jumps larger than its ???? *?? min jumps, the bad effects described for ratios in ]0.0,1.0[ also ???? *?? occur for ratios >= 1.0 but too small regarding System.currentTimeMillis() ???? *?? accuracy variations. ???? * - Ratios too large regarding System.currentTimeMillis() will by definition ???? *?? allow for a "thin current time line" uselessly ahead of the actual current time, ???? *?? i.e. for a (still) thin/continuous but less accurate time. ???? * ???? * The best ratio is the smallest one that does not lead to (a lot of) jumps ???? * (relatively to the actual current time). ???? * Ideally, when System.nanoTime() does not jump, with a good ratio, ???? * the "thin current time line" will converge to being just-above actual ???? * current time line. ???? */ ??? private final double futureToleranceRatio;??? ??? private final long systemTimeZeroMS; ??? ??? private final AtomicReference timeRef = new AtomicReference(); ??? /** ???? * NB: Not having it and future tolerance in a same volatile-referenced object ???? * (to reduce number of accesses to a volatile object), ???? * for minSCTMJumpMS is only accessed when sctm changes, i.e. not so often. ???? * ???? * In milliseconds. ???? * Can only get smaller. ???? */ ??? private final AtomicLong minSCTMJumpMS = new AtomicLong(Long.MAX_VALUE); ??? /** ???? * In nanoseconds. ???? * Can only get smaller. ???? */ ??? private final AtomicLong futureToleranceNS = new AtomicLong(Long.MAX_VALUE); ??? /** ???? * Last retrieved (System.currentTimeMillis() - systemTimeZeroMS). ???? */ ??? private final AtomicLong lastGetSCTM = new AtomicLong(Long.MIN_VALUE); ??? ??? /** ???? * Last returned current time, in nanoseconds. ???? */ ??? private final AtomicLong lastReturnedCTN = new AtomicLong(Long.MIN_VALUE); ??? //-------------------------------------------------------------------------- ??? // PUBLIC METHODS ??? //-------------------------------------------------------------------------- ??? /** ???? * Unless default parameters are redefined by properties, ???? * creates an instance with a future tolerance ratio of 2, ???? * a default initial min sctm jump of 100ms, ???? * and a zero offset from system time. ???? * You most likely would like to use the default instance, ???? * which is of this kind, instead of another one (the most ???? * an instance is used, the most accurate it is), unless ???? * for some reasons you don't want, for example, too many ???? * threads to use your instance. ???? */ ??? public ThinTime() { ??????? this( ??????????????? DEFAULT_FUTURE_TOLERANCE_RATIO, ??????????????? DEFAULT_INITIAL_MIN_SCTM_JUMP_MS, ??????????????? DEFAULT_SYSTEM_TIME_ZERO_MS); ??? } ??? /** ???? * @param futureToleranceRatio Tolerance ratio for the returned time to be ahead ???? *??????? of the time returned by System.currentTimeMillis(). This value is multiplied ???? *??????? with the min time jump (precision) of System.currentTimeMillis(). ???? *??????? Ex. : if system time precision is 10ms, and this ratio is 2, returned time ???? *??????? will be allowed to be up to 20ms ahead of system time. ???? *??????? This value must be 0.0, or a value >= 1.0. ???? * @param initialMinSCTMJumpMS Initial value (in milliseconds) for min date jump between ???? *??????? two consecutive calls to System.currentTimeMillis() returning different values. ???? *??????? This initial value must be higher or equal to the actual min jump, ???? *??????? or we would not end up with a large enough future tolerance and ???? *??????? would be updating reference very frequently; but it must not be too large, ???? *??????? or first returned times could be about as inaccurate than this value. ???? * @param systemTimeZeroMS Offset from system time: returned time ~= system time - offset. ???? */ ??? public ThinTime( ??????????? double futureToleranceRatio, ??????????? long initialMinSCTMJumpMS, ??????????? long systemTimeZeroMS) { ??????? if (!((futureToleranceRatio >= 1.0) || (futureToleranceRatio == 0.0))) { // takes care of NaN ??????????? throw new IllegalArgumentException("future tolerance ratio ["+futureToleranceRatio+"] must be >= 1.0, or equal to zero"); ??????? } ??????? if (initialMinSCTMJumpMS <= 0) { ??????????? throw new IllegalArgumentException("initial min sctm jump ["+initialMinSCTMJumpMS+"] must be > 0"); ??????? } ??????? this.futureToleranceRatio = futureToleranceRatio; ??????? this.systemTimeZeroMS = systemTimeZeroMS; ??????? setMinSCTMJump(initialMinSCTMJumpMS); ??????? long sctm1 = getRawSystemCurrentTimeMillisFromTimeZero(); ??????? long snt = getSNT(); ??????? long sctm2 = getRawSystemCurrentTimeMillisFromTimeZero(); ??????? this.updateTimeRef(sctm1, snt, sctm2); ??? } ??? /** ???? * @return The default instance. ???? */ ??? public static ThinTime getDefaultInstance() { ??????? return DEFAULT_INSTANCE; ??? } ??? /** ???? * In case anyone would like to make use of it. ???? * @return The current time reference. ???? */ ??? public TimeRef getTimeRef() { ??????? return this.timeRef.get(); ??? } ??? ??? /** ???? * @return The future tolerance ratio. ???? */ ??? public double getFutureToleranceRatio() { ??????? return this.futureToleranceRatio; ??? } ??? /** ???? * @return The System.currentTimeMillis() for which this instance, should return time 0. ???? */ ??? public long getSystemTimeZeroMS() { ??????? return this.systemTimeZeroMS; ??? } ??? /** ???? * @return Min recorded time jump, in milliseconds, between two consecutive calls of ???? *???????? System.currentTimeMillis(). This value is > 0 (does not count backward time jumps). ???? */ ??? public long getMinSCTMJumpMS() { ??????? return this.minSCTMJumpMS.get(); ??? } ??? /** ???? * @return The tolerance, in nanoseconds, for returned time to be ahead of ???? *???????? (System.currentTimeMillis() - systemTimeZeroMS). ???? */ ??? public long getFutureToleranceNS() { ??????? return this.futureToleranceNS.get(); ??? } ??? /** ???? * @return Last retrieved (System.currentTimeMillis() - systemTimeZeroMS). ???? */ ??? public long getLastGetSCTM() { ??????? return this.lastGetSCTM.get(); ??? } ??? /** ???? * @return Last returned current time, in nanoseconds. ???? */ ??? public long getLastReturnedCTN() { ??????? return this.lastReturnedCTN.get(); ??? } ??? /* ???? * static time methods (use a default instance of ThinTime) ???? */ ??? ??? public static double currentTimeSeconds() { ??????? return DEFAULT_INSTANCE.currentTimeSeconds_(); ??? } ??? public static long currentTimeMillis() { ??????? return DEFAULT_INSTANCE.currentTimeMillis_(); ??? } ??? public static long currentTimeMicros() { ??????? return DEFAULT_INSTANCE.currentTimeMicros_(); ??? } ??? public static long currentTimeNanos() { ??????? return DEFAULT_INSTANCE.currentTimeNanos_(); ??? } ??? /* ???? * instance time methods ???? */ ??? public double currentTimeSeconds_() { ??????? return currentTimeNanos_() * 1e-9; ??? } ??? public long currentTimeMillis_() { ??????? return currentTimeNanos_()/1000000L; ??? } ??? public long currentTimeMicros_() { ??????? return currentTimeNanos_()/1000L; ??? } ??? public long currentTimeNanos_() { ??????? long ctn; ??????? if (this.futureToleranceRatio == 0.0) { ??????????? // Fast handling for this special case: ??????????? // no need to use all our machinery. ??????????? ctn = getRawSystemCurrentTimeMillisFromTimeZero() * 1000000L; ??????? } else { ??????????? /* ???????????? * Algorithm in short (prefixing volatile variables with an underscore): ???????????? * 1) get sctm1 (and do A = { ???????????? *?????????????????????????? update _lastGetSCTM if needed, ???????????? *?????????????????????????? update _lastReturnedCTN if system time did a backward jump, ???????????? *?????????????????????????? update _minSCTMJump and _futureToleranceNS if needed}) ???????????? * 2) get snt ???????????? * 3) get sctm2 (and do A) ???????????? * 4) retrieve latest _timeReference ???????????? * 5) compute ctn (using retrieved _timeReference, and snt) ???????????? * 6) if computed ctn is outside tolerance range (computed from sctm1, sctm2, and _futureToleranceNS), ???????????? *??? compute and set new _timeReference, and set ctn with reference sctm (*1000000 for ctn is in nanoseconds). ???????????? * 7) if ctn is inferior to _lastReturnedCTN, set it with _lastReturnedCTN value, ???????????? *??? else update _lastReturnedCTN value with ctn. ???????????? * ???????????? * Here is the update policy (i.e. using CAS and stuffs or not) for the volatile variables: ???????????? * - _timeReference: ???????????? *?? NOT a problem if set concurrently in anarchy by multiple threads, ???????????? *?? since it always goes towards a "good" reference. ???????????? *?? ===> Not using CAS for it. ???????????? * - _minSCTMJump and _futureToleranceNS: ???????????? *?? NOT a problem if set concurrently in anarchy by multiple threads, ???????????? *?? as long as they are set together (they are linked), since they can ???????????? *?? only get smaller, and finally don't change anymore. ???????????? *?? Though, it's nice to have them get small ASAP, and doesn't hurt to take care ???????????? *?? of it since they are only set a finite (and small) number of time. ???????????? *?? Also if using "setMinAndGet" to set each of them, no need for synchronization ???????????? *?? or lock to set them together. ???????????? *?? ===> Using CAS and stuffs for these. ???????????? * - _lastGetSCTM and _lastReturnedCTN: ???????????? *?? IMPORTANT not to have them set concurrently in anarchy by multiple threads, ???????????? *?? since we want to keep track of System.currentTimeMillis() backward jumps, ???????????? *?? and don't want to return a time inferior to previously returned time ???????????? *?? (unless system time backward jumps). ???????????? *?? ===> Using CAS and stuffs for these. ???????????? */ ??????????? ??????????? /* ???????????? * Since System.nanoTime() can have jumps, we make sure ???????????? * we won't return an absurd value, by using a security ???????????? * window computed from times returned by System.currentTimeMillis(). ???????????? */ ??????????? long sctm1 = getSystemCurrentTimeMillisFromTimeZero(); ??????????? /* ???????????? * If our thread has a rest here, for a duration d, ???????????? * we will be tolerant to System.nanoTime() jumps in ???????????? * past of -d, when testing (ctn < sctn1). ???????????? * This is no biggie, since the computed current time will ???????????? * remain superior to the time this method was called at. ???????????? */ ??????????? long snt = getSNT(); ??????????? /* ???????????? * If our thread has a rest here, for a duration d, ???????????? * we will be tolerant to System.nanoTime() jumps in ???????????? * future of toleranceToSCTN + d, when testing (ctn > sctn2 + futureTolerance). ???????????? * This is no biggie, since the computed current time will ???????????? * remain inferior to the time this method returns + toleranceToSCTN. ???????????? */ ??????????? long sctm2 = getSystemCurrentTimeMillisFromTimeZero(); ??????????? long sctn1 = sctm1 * 1000000L; ??????????? long sctn2 = sctm2 * 1000000L; ??????????? TimeRef timeRef = this.timeRef.get(); ??????????? ??????????? ctn = timeRef.refSCTM * 1000000L + (snt - timeRef.refSNT); ??????????? /* ???????????? * If system time jumped backward between calls to System.currentTimeMillis(), ???????????? * no biggie, we will just most likely update references according to new ???????????? * system time. ???????????? */ ??????????? if ((ctn < sctn1) || (ctn > sctn2 + this.futureToleranceNS.get())) { ??????????????? // ctn too low or too high: need to update reference ??????????????? // and recompute ctn. ??????????????? ??????????????? /* ???????????????? * ctn too low: ???????????????? * ???????????????? * Three non-exclusive possibilities: ???????????????? * - Our line was below the line "time=actual current time". ???????????????? *?? System.nanoTime() might also have jumped some into the ???????????????? *?? future, but not enough to make our line reach the line ???????????????? *?? "time=actual current time", ???????????????? * - System.nanoTime() did jump in the past (or went past ???????????????? *?? Long.MAX_VALUE), ???????????????? * - futureToleranceRatio is small. ???????????????? */ ??????????????? ??????????????? /* ???????????????? * ctn too high: ???????????????? * ???????????????? * We authorize our computed current time to be a bit ahead ???????????????? * system current time millis, since it changes more often, ???????????????? * hence the tolerance, but too much is too much. ???????????????? * ???????????????? * Two non-exclusive possibilities: ???????????????? * - System.nanoTime() did jump in the future, ???????????????? * - futureToleranceRatio is small. ???????????????? */ ??????????????? ??????????????? timeRef = updateTimeRef(sctm1,snt,sctm2); ??????????????? ctn = timeRef.refSCTM * 1000000L; ??????????? } ??????????? // Making sure we don't return a ctn inferior to a previously returned one, ??????????? // (unless system time went backward, which is handled elsewhere), ??????????? // and updating lastReturnedCTN if needed. ??????????? ctn = setMaxAndGet(this.lastReturnedCTN, ctn); ??????? } ??????? return ctn; ??? } ??? //-------------------------------------------------------------------------- ??? // PROTECTED METHODS ??? //-------------------------------------------------------------------------- ??? ??? /* ???? * Overridable for use of custom time sources (for tests or else). ???? */ ??? ??? protected long getSCTM() { ??????? return System.currentTimeMillis(); ??? } ??? ??? protected long getSNT() { ??????? return System.nanoTime(); ??? } ??? ??? //-------------------------------------------------------------------------- ??? // PRIVATE METHODS ??? //-------------------------------------------------------------------------- ??? ??? /** ???? * This method updates minSCTMJump and related values as needed, ???? * and keeps track of system time backward jumps. ???? */ ??? private long getSystemCurrentTimeMillisFromTimeZero() { ??????? long sctm; ??????? long previousSCTM; ??????? // Most of the time, this loop should only ??????? // do one round, and it could do two if done near ??????? // the time the value returned by System.currentTimeMillis() ??????? // changes. ??????? do { ??????????? previousSCTM = this.lastGetSCTM.get(); ??????????? sctm = getRawSystemCurrentTimeMillisFromTimeZero(); ??????????? // CAS fails when last get SCTM was changed ??????????? // by another thread since we read it last. ??????? } while (!this.lastGetSCTM.compareAndSet(previousSCTM, sctm)); ??????? // Here, we are sure sctm has been retrieved while ??????? // lastGetSCTM value was previousSCTM. ??????? if (sctm != previousSCTM) { ??????????? // "rare" case: sctm changed. ??????????? if (sctm < previousSCTM) { ??????????????? // System time went backward: need to reset lastReturnedCTN, ??????????????? // or our clock will be stalled until system time reaches ??????????????? // lastGetSCTM again. ??????????????? this.lastReturnedCTN.set(Long.MIN_VALUE); ??????????? } else { ??????????????? long dtMS = sctm - previousSCTM; ??????????????? if (dtMS < 0) { ??????????????????? // Jump was so large we had overflow: ??????????????????? // obviously, not a candidate value ??????????????????? // to update min possible jump! ??????????????? } else { ??????????????????? // If time jump was smaller than smallest ??????????????????? // registered, we update it. ??????????????????? if (dtMS < this.minSCTMJumpMS.get()) { ??????????????????????? setMinSCTMJump(dtMS); ??????????????????? } ??????????????? } ??????????? } ??????? } ??????? return sctm; ??? } ??? /** ???? * Method to be used with caution, since it does not update ???? * anything of our multiple time related variables... ???? */ ??? private long getRawSystemCurrentTimeMillisFromTimeZero() { ??????? return getSCTM() - this.systemTimeZeroMS; ??? } ??? /** ???? * {sctm1, snt, sctm2} : recent values of System.currentTimeMillis(), ???? * System.nanoTime(), and System.currentTimeMillis(), retrieved in ???? * that order. ???? * @return The new time reference. ???? */ ??? private TimeRef updateTimeRef( ??????????? long sctm1, ??????????? long snt, ??????????? long sctm2) { ??????? /* ???????? * Using counter to prevent "infinite" loop, ???????? * in case System.currentTimeMillis() is really thin, ???????? * and our thread really lazy... ???????? * At worse, currentTimeNanos() will be less "thin" ???????? * and closer to System.currentTimeMillis(). ???????? */ ??????? int counter = MAX_NBR_OF_TIME_REF_UPDATE_RE_ATTEMPTS; ??????? while ((sctm1 != sctm2) && (counter-- != 0)) { ??????????? sctm1 = sctm2; ??????????? snt = getSNT(); ??????????? sctm2 = getSystemCurrentTimeMillisFromTimeZero(); ??????? } ??????? /* ???????? * In case sctm1 != sctm2, and even if sctm1 > sctm2 (backward ???????? * system time jump), we can use either value for SCTM reference: ???????? * our "thin current time line", defined by our references, ???????? * might be well below (with sctm1) or well above (with sctm2) ???????? * actual current time line, but in both cases, SCTM reference ???????? * will be a system time computed while currentTimeNanos() was ???????? * being called, so a valid time to return, and for next calls, ???????? * as for each call, time window validity will be checked again. ???????? */ ??????? TimeRef newTimeRef = new TimeRef(sctm1,snt); ??????? ??????? this.timeRef.set(newTimeRef); ??????? ??????? return newTimeRef; ??? } ??? ??? private void setMinSCTMJump(long newValue) { ??????? setMinAndGet(this.minSCTMJumpMS, newValue); ??????? long newFutureToleranceNS = (long)Math.ceil(newValue * (this.futureToleranceRatio * 1000000.0)); ??????? setMinAndGet(this.futureToleranceNS, newFutureToleranceNS); ??? } ??? /** ???? * Atomically sets the specified atomic long with min(atomic long value, specified value), ???? * and returns the new atomic long value (which might have not changed). ???? */ ??? private static long setMinAndGet(AtomicLong atomic, long value) { ??????? long tmpLastReturned; ??????? do { ??????????? tmpLastReturned = atomic.get(); ??????????? if (tmpLastReturned <= value) { ??????????????? return tmpLastReturned; ??????????? } ??????????? // Here, value < tmpLastReturned, ??????????? // so we will try to set it as new value. ??????? } while (!atomic.compareAndSet(tmpLastReturned, value)); ??????? return value; ??? } ??? ??? /** ???? * Atomically sets the specified atomic long with max(atomic long value, specified value), ???? * and returns the new atomic long value (which might have not changed). ???? */ ??? private static long setMaxAndGet(AtomicLong atomic, long value) { ??????? long tmpLastReturned; ??????? do { ??????????? tmpLastReturned = atomic.get(); ??????????? if (tmpLastReturned >= value) { ??????????????? return tmpLastReturned; ??????????? } ??????????? // Here, value > tmpLastReturned, ??????????? // so we will try to set it as new value. ??????? } while (!atomic.compareAndSet(tmpLastReturned, value)); ??????? return value; ??? } } package thintime; public class ThinTimePerf { ? ??? //-------------------------------------------------------------------------- ??? // PUBLIC METHODS ??? //-------------------------------------------------------------------------- ??? ??? public static void main(String[] args) { ??????? System.out.println("--- "+ThinTimePerf.class.getSimpleName()+" ---"); ??????? ??????? test_granularity(); ??????? ??????? System.out.println(""); ??????? System.out.println("--- done ---"); ??? } ??? ??? //-------------------------------------------------------------------------- ??? // PRIVATE METHODS ??? //-------------------------------------------------------------------------- ??? private static double sRounded(long ns) { ??????? return Math.round(ns/1e6)/1e3; ??? } ??? private static void test_granularity() { ??????? ??????? final int nbrOfCalls = 10 * 1000 * 1000; ??????? ??????? System.out.println(""); ??????? System.out.println("--- testing granularity : loops of "+nbrOfCalls+" calls ---"); ??????? long previousTime = 0; ??????? long time; ??????? long a; ??????? long b; ??????? ??????? int nbrOfChanges; ??????? ??????? /* ???????? * System ???????? */ ??????? ??????? nbrOfChanges = 0; ??????? a = System.nanoTime(); ??????? for (int i=0;i (1000L * 1000L * 1000L)) { ??????????????????????? System.err.println("spent more than 1 second (maybe too many threads) : "+deltaRefNS+" ns"); ??????????????????????? assertTrue(false); ??????????????????? } else { ??????????????????????? if (ctn < previousCTN) { ??????????????????????????? // If actual time backward jumps a bit, but we don't ??????????????????????????? // notice, ctn might also backward jump and we might ??????????????????????????? // notice it, so it's not necessarily abnormal. ??????????????????????????? System.err.println("ctn backward jump : "+(ctn - previousCTN)+" ns"); ??????????????????????????? assertTrue(false); ??????????????????????? } ??????????????????????? if (ctn < ref1NS) { ??????????????????????????? System.err.println("ctn ["+ctn+"] < ref1NS ["+ref1NS+"]"); ??????????????????????????? assertTrue(false); ??????????????????????? } else if (ctn > ref2NS + forwardToleranceNS) { ??????????????????????????? long surplus = (ctn - (ref2NS + forwardToleranceNS)); ??????????????????????????? System.err.println("ctn ["+ctn+"] > ref2NS ["+ref2NS+"] + forwardToleranceNS ["+forwardToleranceNS+"] by "+surplus+" ns"); ??????????????????????????? assertTrue(false); ??????????????????????? } ??????????????????? } ??????????????? } ??????????????? previousRefNS = ref2NS; ??????????????? previousCTN = ctn; ??????????? } ??????? } ??? } ??? ??? //-------------------------------------------------------------------------- ??? // MEMBERS ??? //-------------------------------------------------------------------------- ??? ??? // We consider the average granularity of ThinTime (for currentTimeMicros ??? // and currentTimeNanos) must be at least 10 microseconds. ??? private static final long MIN_THIN_TIME_GRANULARITY_NS = 10L * 1000L; ??? ??? private static final long S_TO_MS = 1000L; ??? private static final long MS_TO_NS = 1000L * 1000L; ??? private static final long S_TO_NS = 1000L * 1000L * 1000L; ??? //-------------------------------------------------------------------------- ??? // PUBLIC METHODS ??? //-------------------------------------------------------------------------- ??? ??? public void test_currentTimeMillis() { ??????? final long toleranceMS = 1000L; ??????? assertTrue(Math.abs(ThinTime.currentTimeMillis() - System.currentTimeMillis()) < toleranceMS); ??? } ??? ??? public void test_currentTimeMicros_granularity() { ??????? final long toleranceMS = 1000L; ??????? assertTrue(Math.abs(ThinTime.currentTimeMicros()/1000L - System.currentTimeMillis()) < toleranceMS); ??????? ??????? final int nbrOfRounds = 100000; ??????? ??????? long previousTime = 0; ??????? long time; ??????? long dateA; ??????? long dateB; ??????? ??????? int nbrOfChanges; ??????? ??????? nbrOfChanges = 0; ??????? dateA = System.nanoTime(); ??????? for (int i=0;i= (long)((dateB - dateA)/(double)MIN_THIN_TIME_GRANULARITY_NS)); ??? } ??? ??? public void test_currentTimeNanos_granularity() { ??????? final long toleranceMS = 1000L; ??????? assertTrue(Math.abs(ThinTime.currentTimeNanos()/1000000L - System.currentTimeMillis()) < toleranceMS); ??????? ??????? final int nbrOfRounds = 100000; ??????? long previousTime = 0; ??????? long time; ??????? long dateA; ??????? long dateB; ??????? ??????? int nbrOfChanges; ??????? ??????? nbrOfChanges = 0; ??????? dateA = System.nanoTime(); ??????? for (int i=0;i= (long)((dateB - dateA)/(double)MIN_THIN_TIME_GRANULARITY_NS)); ??? } ??? public void test_sequentialBehavior_minSCTMJump() { ??? ??? final double futureToleranceRatio = 2.0; ??? ??? final long initialMinSCTMJumpMS = 1000L; ??? ??? final long systemTimeZeroMS = 123; ??? ??? MyThinTime tt = new MyThinTime( ??? ??? ??? ??? futureToleranceRatio, ??? ??? ??? ??? initialMinSCTMJumpMS, ??? ??? ??? ??? systemTimeZeroMS); ??? ??? ??? ??? assertEquals(initialMinSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // doesn't get lower on first call, ??? ??? // which initializes previous SCTM value ??? ??? tt.sctm += 100L; ??? ??? tt.currentTimeNanos_(); ??? ??? assertEquals(initialMinSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // gets lower ??? ??? tt.sctm += 100L; ??? ??? tt.currentTimeNanos_(); ??? ??? assertEquals(100L, tt.getMinSCTMJumpMS()); ??? ??? ??? ??? // gets lower again ??? ??? tt.sctm += 10L; ??? ??? tt.currentTimeNanos_(); ??? ??? assertEquals(10L, tt.getMinSCTMJumpMS()); ??? ??? ??? ??? // doesn't grow ??? ??? tt.sctm += 100L; ??? ??? tt.currentTimeNanos_(); ??? ??? assertEquals(10L, tt.getMinSCTMJumpMS()); ??? } ??? public void test_sequentialBehavior_regular() { ??? ??? final double futureToleranceRatio = 2.0; ??? ??? final long initialMinSCTMJumpMS = 1000L; ??? ??? final long systemTimeZeroMS = 123; ??? ??? MyThinTime tt = new MyThinTime( ??? ??? ??? ??? futureToleranceRatio, ??? ??? ??? ??? initialMinSCTMJumpMS, ??? ??? ??? ??? systemTimeZeroMS); ??? ??? ??? ??? long expectedNS; ??? ??? long expectedRefSCTM; ??? ??? long expectedRefSNT; ??? ??? long minSCTMJumpMS; ??? ??? // initial time ??? ??? expectedNS = (tt.sctm - systemTimeZeroMS) * MS_TO_NS; ??? ??? expectedRefSCTM = -systemTimeZeroMS; ??? ??? expectedRefSNT = 0; ??? ??? minSCTMJumpMS = initialMinSCTMJumpMS; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // sctm and snt both getting ahead 10 seconds ??? ??? tt.sctm += 10 * S_TO_MS; ??? ??? tt.snt += 10 * S_TO_NS; ??? ??? expectedNS += 10 * S_TO_NS; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump (smaller than our jump) ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? } ??? public void test_sequentialBehavior_backwardJumps() { ??? ??? final double futureToleranceRatio = 2.0; ??? ??? final long initialMinSCTMJumpMS = 1000L; ??? ??? final long systemTimeZeroMS = 123; ??? ??? MyThinTime tt = new MyThinTime( ??? ??? ??? ??? futureToleranceRatio, ??? ??? ??? ??? initialMinSCTMJumpMS, ??? ??? ??? ??? systemTimeZeroMS); ??? ??? ??? ??? long expectedNS = tt.currentTimeNanos_(); ??? ??? long expectedRefSCTM = tt.getTimeRef().getRefSCTM(); ??? ??? long expectedRefSNT = tt.getTimeRef().getRefSNT(); ??? ??? long minSCTMJumpMS = tt.getMinSCTMJumpMS(); ??? ??? // snt jumped 1ns forward: cnt changes accordingly, ??? ??? // and time ref is not recomputed ??? ??? tt.snt += 1; ??? ??? expectedNS += 1; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // snt jumped back 1ns: not returning a time < to previously returned, ??? ??? // but since computed ctn is not < sctm, time ref is not recomputed ??? ??? tt.snt -= 1; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? ??? ??? // snt jumped backward 1ns again: not returning a time < to previously returned, ??? ??? // and since computed ctn is < sctm, time ref is recomputed ??? ??? tt.snt -= 1; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call changed time ref ??? ??? expectedRefSCTM = tt.sctm - systemTimeZeroMS; ??? ??? expectedRefSNT = tt.snt; ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? ??? ??? // sctm jumped backward, of exactly "future tolerance ratio * min SCTM jump": ??? ??? // ctn just goes backward 1ns (due to previous backward jump of stn), ??? ??? // and time ref is unchanged ??? ??? tt.sctm -= (long)(futureToleranceRatio * minSCTMJumpMS); ??? ??? expectedNS -= 1; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? ??? ??? // sctm jumped backward 1ms, i.e. now computed ctn is past future tolerance. ??? ??? // Backward time jump is detected: time ref is recomputed. ??? ??? tt.sctm -= 1; ??? ??? expectedNS = (tt.sctm - systemTimeZeroMS) * MS_TO_NS; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call did change time ref ??? ??? expectedRefSCTM = tt.sctm - systemTimeZeroMS; ??? ??? expectedRefSNT = tt.snt; ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump (1ms is smaller, but not considering backward jumps) ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? } ??? public void test_sequentialBehavior_forwardJumps() { ??? ??? final double futureToleranceRatio = 2.0; ??? ??? final long initialMinSCTMJumpMS = 1000L; ??? ??? final long systemTimeZeroMS = 123; ??? ??? MyThinTime tt = new MyThinTime( ??? ??? ??? ??? futureToleranceRatio, ??? ??? ??? ??? initialMinSCTMJumpMS, ??? ??? ??? ??? systemTimeZeroMS); ??? ??? ??? ??? long deltaNS; ??? ??? ??? ??? long expectedNS = tt.currentTimeNanos_(); ??? ??? long expectedRefSCTM = tt.getTimeRef().getRefSCTM(); ??? ??? long expectedRefSNT = tt.getTimeRef().getRefSNT(); ??? ??? long minSCTMJumpMS = tt.getMinSCTMJumpMS(); ??? ??? ??? ??? // moving snt at future tolerance ??? ??? deltaNS = (long)(futureToleranceRatio * minSCTMJumpMS * MS_TO_NS); ??? ??? tt.snt += deltaNS; ??? ??? expectedNS += deltaNS; ??? ??? // computing ctn ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call didn't change time ref ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // moving snt 1ns past future tolerance: ??? ??? // won't go past it, and will recompute time ref, ??? ??? // but won't return "sctm - offset" as current time, ??? ??? // since this would make returned time jump backward: ??? ??? // instead, returns the same as previously returned ??? ??? tt.snt += 1; ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call did change time ref ??? ??? expectedRefSCTM = tt.sctm - systemTimeZeroMS; ??? ??? expectedRefSNT = tt.snt; ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? ??? // moving sctm 10s ahead, to get away of previous returned time, ??? ??? // and moving snt 1ns past future tolerance: ??? ??? // time ref will be recomputed ??? ??? tt.sctm += 10 * S_TO_MS; ??? ??? tt.snt += 10 * S_TO_NS + (long)(futureToleranceRatio * minSCTMJumpMS * MS_TO_NS) + 1; ??? ??? expectedNS = (tt.sctm - systemTimeZeroMS) * MS_TO_NS; ??? ??? assertEquals(expectedNS, tt.currentTimeNanos_()); ??? ??? // call did change time ref ??? ??? expectedRefSCTM = tt.sctm - systemTimeZeroMS; ??? ??? expectedRefSNT = tt.snt; ??? ??? assertEquals(expectedRefSCTM, tt.getTimeRef().getRefSCTM()); ??? ??? assertEquals(expectedRefSNT, tt.getTimeRef().getRefSNT()); ??? ??? // call did't change min SCTM jump (which is smaller) ??? ??? assertEquals(minSCTMJumpMS, tt.getMinSCTMJumpMS()); ??? } ??? ??? /* ???? * ???? */ ??? ??? public static void test_currentTimeNanos_behavior() { ??????? final ExecutorService executor = Executors.newCachedThreadPool(); ??????? ??????? final long nbrOfCalls = 1000L * 1000L; ??????? ??????? final int nbrOfThreads = 1 + Runtime.getRuntime().availableProcessors(); ??????? ??????? for (int i=0;i Changeset: 8da26d5c32a7 Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8da26d5c32a7 Added tag jdk8-b13 for changeset 26fb81a1e9ce ! .hgtags Changeset: a62a0f35eb9c Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a62a0f35eb9c Merge Changeset: f9b3e6b2aa2c Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9b3e6b2aa2c Merge Changeset: ea2ab83ce564 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ea2ab83ce564 Merge Changeset: 8f525559ae73 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8f525559ae73 Merge Changeset: 23aa7f2c80a2 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/23aa7f2c80a2 Merge Changeset: a4f28069d44a Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/a4f28069d44a Added tag jdk8-b14 for changeset 23aa7f2c80a2 ! .hgtags From lana.steuck at oracle.com Fri Nov 18 22:37:31 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:31 +0000 Subject: hg: jdk8/tl/jaxp: 7 new changesets Message-ID: <20111118223731.9AF06473E1@hg.openjdk.java.net> Changeset: e7172d80a8f4 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e7172d80a8f4 Added tag jdk8-b13 for changeset bcc739229f63 ! .hgtags Changeset: 7adf14d6060c Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7adf14d6060c Merge Changeset: d239aa024b6e Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d239aa024b6e Merge Changeset: eca33f89c823 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eca33f89c823 Merge Changeset: 0ed9ae36ee2a Author: asaha Date: 2011-11-07 21:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0ed9ae36ee2a Merge Changeset: 9d0c9d638757 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9d0c9d638757 Merge Changeset: 804f666d6d44 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/804f666d6d44 Added tag jdk8-b14 for changeset 9d0c9d638757 ! .hgtags From lana.steuck at oracle.com Fri Nov 18 22:37:36 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:36 +0000 Subject: hg: jdk8/tl/jaxws: 9 new changesets Message-ID: <20111118223737.3E29E473E2@hg.openjdk.java.net> Changeset: f502a343a92e Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f502a343a92e Added tag jdk8-b13 for changeset adf2a6b5fde1 ! .hgtags Changeset: 75a652e72489 Author: asaha Date: 2011-06-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/75a652e72489 Merge Changeset: b058cae6fd3b Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b058cae6fd3b Merge Changeset: 61c046c6895a Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/61c046c6895a Merge Changeset: 9e82b46cd4fa Author: asaha Date: 2011-07-25 11:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/9e82b46cd4fa 7046794: Configurable behavior for server-side stacktraces Reviewed-by: ramap ! jaxws.properties Changeset: c78fccb01d4e Author: asaha Date: 2011-11-07 21:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c78fccb01d4e Merge Changeset: cae6db74d6af Author: asaha Date: 2011-11-10 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/cae6db74d6af 7110676: Update jaf source download url for jaxws Reviewed-by: ramap ! jaxws.properties Changeset: 54c4bf4b83ec Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/54c4bf4b83ec Merge Changeset: c9ab96ff23d5 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c9ab96ff23d5 Added tag jdk8-b14 for changeset 54c4bf4b83ec ! .hgtags From lana.steuck at oracle.com Fri Nov 18 22:37:26 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:26 +0000 Subject: hg: jdk8/tl/corba: 9 new changesets Message-ID: <20111118223744.5C049473E3@hg.openjdk.java.net> Changeset: 6f601a737e0f Author: katleman Date: 2011-11-10 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6f601a737e0f Added tag jdk8-b13 for changeset 5b9d9b839d3d ! .hgtags Changeset: d84682019b5f Author: asaha Date: 2011-06-27 11:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d84682019b5f Merge Changeset: 9c20c1e7cdd9 Author: asaha Date: 2011-06-28 08:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9c20c1e7cdd9 Merge Changeset: cb5aec0570a5 Author: asaha Date: 2011-07-19 11:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb5aec0570a5 Merge Changeset: 21369018a679 Author: mbankal Date: 2011-08-09 05:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/21369018a679 7055902: Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: 058c18d237a9 Author: asaha Date: 2011-11-07 21:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/058c18d237a9 Merge Changeset: e59c47de1ad8 Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e59c47de1ad8 Merge Changeset: 99925e8d1b86 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/99925e8d1b86 Added tag jdk8-b14 for changeset e59c47de1ad8 ! .hgtags Changeset: 7da69e7175a7 Author: lana Date: 2011-11-18 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/7da69e7175a7 Merge From lana.steuck at oracle.com Fri Nov 18 22:37:17 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:17 +0000 Subject: hg: jdk8/tl/hotspot: 8 new changesets Message-ID: <20111118223755.A0417473E4@hg.openjdk.java.net> Changeset: 5c8c7bef6403 Author: jcoomes Date: 2011-10-28 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c8c7bef6403 7106092: Bump the hs23 build number to 05 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: d5c4c73aa855 Author: dholmes Date: 2011-10-27 18:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5c4c73aa855 7104173: sun/tools tests fail with debug build after 7012206 Summary: Disable PrintVMOptions in embedded debug builds so tests are unaffected by extra output Reviewed-by: twisti, coleenp, phh, fparain, dsamersoff ! src/share/vm/runtime/globals.hpp Changeset: 6da94c5a6746 Author: dholmes Date: 2011-10-30 18:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6da94c5a6746 Merge Changeset: 95009f678859 Author: brutisso Date: 2011-11-01 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/95009f678859 7106766: Move the precompiled header from the src/share/vm directory Summary: Moved precompiled.hpp to src/share/vm/precompiled Reviewed-by: coleenp, dholmes Contributed-by: rbackman ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/windows/makefiles/vm.make - src/share/vm/precompiled.hpp + src/share/vm/precompiled/precompiled.hpp Changeset: 3e609627e780 Author: jcoomes Date: 2011-11-04 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3e609627e780 Merge - src/share/vm/precompiled.hpp Changeset: b92ca8e229d2 Author: jcoomes Date: 2011-11-04 12:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b92ca8e229d2 Added tag hs23-b05 for changeset 3e609627e780 ! .hgtags Changeset: 088d09a130ff Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/088d09a130ff Added tag jdk8-b13 for changeset b92ca8e229d2 ! .hgtags Changeset: 883328bfc472 Author: katleman Date: 2011-11-17 10:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/883328bfc472 Added tag jdk8-b14 for changeset 088d09a130ff ! .hgtags From lana.steuck at oracle.com Fri Nov 18 22:37:48 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:37:48 +0000 Subject: hg: jdk8/tl/langtools: 9 new changesets Message-ID: <20111118223811.BD4E8473E5@hg.openjdk.java.net> Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: f07d6f55d39a Author: lana Date: 2011-11-18 11:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f07d6f55d39a Merge From lana.steuck at oracle.com Fri Nov 18 22:39:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 18 Nov 2011 22:39:47 +0000 Subject: hg: jdk8/tl/jdk: 50 new changesets Message-ID: <20111118224756.C723B473E6@hg.openjdk.java.net> Changeset: bfd720647db2 Author: yhuang Date: 2011-10-31 20:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd720647db2 7077119: remove past transition dates from CurrencyData.properties file Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt Changeset: cfc6fd491b97 Author: yhuang Date: 2011-10-31 21:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfc6fd491b97 6755060: Collator.compare() does not compare correctly for the Thai locale Reviewed-by: naoto ! src/share/classes/sun/text/resources/CollationData_th.java + test/sun/text/resources/Collator/Bug6755060.java Changeset: 0549410acf26 Author: yhuang Date: 2011-10-31 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0549410acf26 Merge Changeset: f3227efde13d Author: yhuang Date: 2011-10-31 21:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3227efde13d 7101495: In Latvia first day of week is Monday Reviewed-by: naoto, peytoia ! src/share/classes/sun/util/resources/CalendarData_lv.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: ab837acc60fb Author: yhuang Date: 2011-10-31 21:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab837acc60fb Merge Changeset: 631ee738378a Author: mfang Date: 2011-11-03 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/631ee738378a Merge Changeset: 94e5604022fa Author: ngmr Date: 2011-09-15 19:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94e5604022fa 6988099: jvmti demos missing Publisher (COMPANY resource) in dlls/exes on windows Summary: Add creation/linking of resource data to link step for demos on Windows Reviewed-by: dcubed, zgu, ngmr, ohair Contributed-by: Sean Chou ! make/common/Demo.gmk Changeset: 5791714b9472 Author: ohair Date: 2011-11-04 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5791714b9472 Merge Changeset: 4cb2e8679b27 Author: katleman Date: 2011-11-09 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4cb2e8679b27 Merge Changeset: 52bd7fc8fcb0 Author: katleman Date: 2011-11-10 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/52bd7fc8fcb0 Added tag jdk8-b13 for changeset 4cb2e8679b27 ! .hgtags Changeset: 9de1dbf8c9be Author: lana Date: 2011-10-26 17:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9de1dbf8c9be Merge - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/tools/jar/JarImageSource.java Changeset: 76defa20906a Author: ngmr Date: 2011-09-23 15:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76defa20906a 7105640: Unix printing does not check the result of exec'd lpr/lp command Summary: Add checking, exception for spool process failure Reviewed-by: prr, jgodinez Contributed-by: Neil Richards ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/UnixPrintJob.java Changeset: 4544585a3cea Author: lana Date: 2011-11-05 14:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4544585a3cea Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: aa3f5117c485 Author: rupashka Date: 2011-10-17 15:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa3f5117c485 7099251: javax.swing.text.html.HTMLDocument.insertAfterStart(null, something) throws NPE Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 4f74e3fdf86b Author: rupashka Date: 2011-10-17 16:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f74e3fdf86b 7100004: javax.swing.JTable.setAutoCreateRowSorter(boolean autoCreateRowSorter) should mention default value Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/javax/swing/JTable.java Changeset: f1dbc62c7c6d Author: rupashka Date: 2011-10-17 17:19 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1dbc62c7c6d 7077293: javax/swing/JComponent/4337267/bug4337267.java failed on windows 2003 Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: a2f5d7049258 Author: dbuck Date: 2011-10-17 19:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2f5d7049258 6887286: StackOverflowError at sun.awt.image.ImageWatched$WeakLink.isWatcher Summary: Fixed OffScreenImageSource to call imageComplete() with SINGLEFAMEDONE, not STATICIMAGEDONE. This fixed memory leak (that caused SOFE when we use recursion to iterate over linked list). Reviewed-by: bae ! src/share/classes/sun/awt/image/OffScreenImageSource.java Changeset: 7636a62aba7e Author: anthony Date: 2011-11-01 18:01 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7636a62aba7e 7104625: sun.awt.X11.XEvent is creating 600 MB of char[] for no good reason Summary: Wrap logging calls with if(){} statements Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/XComponentPeer.java Changeset: ac55f169fadd Author: anthony Date: 2011-11-01 18:03 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac55f169fadd 7105529: XAWT: Optimize getFieldsAsString() methods generated by WrapperGenerator Summary: Replace string concatenation with StringBuilder.append() Reviewed-by: anthony, son Contributed-by: Federico Tello Gentile ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java Changeset: 41610a897379 Author: rupashka Date: 2011-11-02 14:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/41610a897379 6624077: Regression test fails: closed/javax/swing/ToolTipManager/6256140/bug6256140.java Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/ToolTipManager/Test6256140.java Changeset: 8068f1584715 Author: mrkam Date: 2011-11-02 17:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8068f1584715 7074853: TransparentRuler demos Readme should mention the correct jar file name Reviewed-by: rupashka ! src/share/demo/jfc/TransparentRuler/README.txt Changeset: 323f6d046cc9 Author: rupashka Date: 2011-11-02 23:53 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/323f6d046cc9 7049024: DnD fails with JTextArea and JTextField Reviewed-by: rupashka Contributed-by: Sean Chou ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/JTextArea/7049024/bug7049024.java Changeset: 7c29751a9331 Author: rupashka Date: 2011-11-03 14:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c29751a9331 6955919: Intermittent ClassCastException in bug4492274 test Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JEditorPane/4492274/bug4492274.java + test/javax/swing/JEditorPane/4492274/test.html Changeset: 1c0624d9a2b6 Author: ngmr Date: 2011-10-13 13:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c0624d9a2b6 7107957: AWT: Native code should include fcntl.h and unistd.h rather than sys/fcntl.h and sys/unistd.h Summary: Use POSIX defined includes for unistd.h and fcntl.h Reviewed-by: anthony, ngmr Contributed-by: Charles Lee ! src/solaris/native/sun/awt/splashscreen/splashscreen_config.h Changeset: adb31ff942ef Author: rupashka Date: 2011-11-07 16:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adb31ff942ef 7080203: JTree.getSelectionPaths() now returns empty array instead of null Reviewed-by: malenkov ! src/share/classes/javax/swing/JTree.java Changeset: d219e0b11327 Author: lana Date: 2011-11-07 10:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d219e0b11327 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/classes/sun/tools/jar/JarImageSource.java - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: f8a3dff76b48 Author: rupashka Date: 2011-11-08 14:36 +0300 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8a3dff76b48 7107585: Test incorrect calculate position of object on frame Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JSlider/6348946/bug6348946.java Changeset: af4fb33fca29 Author: lana Date: 2011-11-08 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af4fb33fca29 Merge Changeset: 0bb498332894 Author: lana Date: 2011-11-08 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bb498332894 Merge Changeset: 51db54a3b953 Author: lana Date: 2011-11-14 18:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51db54a3b953 Merge Changeset: 3b2128c89361 Author: alanb Date: 2011-06-15 14:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b2128c89361 7000600: InputStream.skip() makes sensitive data accessible to malicious code Reviewed-by: hawtin, chegar ! src/share/classes/java/io/InputStream.java Changeset: 06e0d91548b3 Author: anthony Date: 2011-06-21 20:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06e0d91548b3 7022113: Security icon can be moved behind the window using the com.sun.SecurityWarning.setPosition() method Reviewed-by: art, dcherepanov ! src/windows/native/sun/windows/awt_Window.cpp Changeset: d32b75c73389 Author: alanb Date: 2011-06-27 20:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d32b75c73389 7059259: (process) ProcessBuilder.start permission check should be improved when redirecting output to append Reviewed-by: hawtin ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 446b13a08aca Author: asaha Date: 2011-06-27 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/446b13a08aca Merge Changeset: 4fdd1a44e846 Author: asaha Date: 2011-06-27 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fdd1a44e846 Merge Changeset: 3e42f7893861 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e42f7893861 Merge Changeset: f578448792b9 Author: ksrini Date: 2011-07-15 13:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f578448792b9 7057857: SIGSEGV [libunpack.so] store_Utf8_char(signed char*, unsigned short) in java.util.jar.pack200 Reviewed-by: jrose, asaha, hawtin ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.cpp ! src/share/native/com/sun/java/util/jar/pack/utils.h Changeset: 4b20375fe623 Author: asaha Date: 2011-07-19 11:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b20375fe623 Merge - src/share/classes/sun/misc/JavaxSecurityAuthKerberosAccess.java - test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/InterruptedIO.java Changeset: bc9c70e57f62 Author: asaha Date: 2011-07-20 09:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc9c70e57f62 7032417: Fix for 6981922 does not address multiple VM case Reviewed-by: michaelm ! src/share/classes/sun/net/ResourceManager.java Changeset: a7177942302f Author: asaha Date: 2011-07-20 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7177942302f 7023640: calculation for malloc size in TransformHelper.c could overflow an integer Reviewed-by: flar ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 6c76f2a49061 Author: denis Date: 2011-07-22 21:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c76f2a49061 7019773: AWTKeyStroke.ctor is a mutable static Reviewed-by: art ! src/share/classes/java/awt/AWTKeyStroke.java Changeset: b25558c39ffc Author: smarks Date: 2011-08-30 14:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b25558c39ffc 7077466: fix for RMI DGC Reviewed-by: valeriep ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: efd8035f3d14 Author: smarks Date: 2011-08-30 17:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efd8035f3d14 7083012: fix for RMI Registry Reviewed-by: jdn, valeriep ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java Changeset: 27bda11f1330 Author: smarks Date: 2011-09-21 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27bda11f1330 7092186: adjust package access in rmiregistry Reviewed-by: asaha, coffeys ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 42eb725f739c Author: xuelei Date: 2011-09-29 17:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42eb725f739c 7064341: jsse/runtime security problem Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargeBufs.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java Changeset: 53a16cf28db3 Author: xuelei Date: 2011-09-30 18:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53a16cf28db3 7096936: issue in jsse/runtime 7096937: TEST: com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java need modification as a result of TLS fix Reviewed-by: wetmore, jdn, xuelei ! src/share/classes/com/sun/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java Changeset: 27a8f4fc555a Author: asaha Date: 2011-11-14 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27a8f4fc555a Merge ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/tools/jstatd/jstatdExternalRegistry.sh Changeset: 99632935785e Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99632935785e Merge Changeset: 00e2c88e2234 Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00e2c88e2234 Added tag jdk8-b14 for changeset 99632935785e ! .hgtags Changeset: cd37d8066437 Author: lana Date: 2011-11-18 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd37d8066437 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From brandon.passanisi at oracle.com Sat Nov 19 01:21:31 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Fri, 18 Nov 2011 17:21:31 -0800 Subject: Code Review Request for Bug #4802647 Message-ID: <4EC7049B.2090605@oracle.com> Hello core-libs-dev at openjdk.java.net. Please review the following patch to fix Bug 4802647 (coll) NullPointerException not thrown by AbstractCollection.retainAll/removeAll: The fix is quite small and I have included a test program, all of which can be found within the following webrev: http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ Thanks. -- Oracle Brandon Passanisi | Principle Member of Technical Staff Green Oracle Oracle is committed to developing practices and products that help protect the environment From mandy.chung at oracle.com Sat Nov 19 07:04:53 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 18 Nov 2011 23:04:53 -0800 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4EC688DC.9070407@oracle.com> References: <4EC688DC.9070407@oracle.com> Message-ID: <4EC75515.1040804@oracle.com> Gary, On 11/18/11 8:33 AM, Gary Adams wrote: > I think this change is ready to commit, just need > a sponsor for the last push (Mandy/David?). > I may but I haven't had time to follow the discussion these test bug fixes. It may be best if one of the reviewers help push the fix for you. If no one sponsors it, I will do it next week. Mandy From alan.bateman at oracle.com Sat Nov 19 20:09:45 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 19 Nov 2011 20:09:45 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20111119201024.60B18473FC@hg.openjdk.java.net> Changeset: c98235762b30 Author: alanb Date: 2011-11-19 19:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c98235762b30 6818464: TEST_BUG: java/util/Timer/KillThread.java failing intermittently Reviewed-by: dholmes, alanb, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 8be37eae9598 Author: alanb Date: 2011-11-19 19:59 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8be37eae9598 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Reviewed-by: dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/Args.java Changeset: 450c17e4808d Author: alanb Date: 2011-11-19 20:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/450c17e4808d 6860309: TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Reviewed-by: alanb, dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java From jim.holmlund at sun.com Sun Nov 20 00:00:54 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Sun, 20 Nov 2011 00:00:54 +0000 Subject: hg: jdk8/tl/langtools: 7110611: compiler message file broken for javac -fullversion Message-ID: <20111120000059.A5396473FE@hg.openjdk.java.net> Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/07599bd780ca 7110611: compiler message file broken for javac -fullversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java From Alan.Bateman at oracle.com Sun Nov 20 19:14:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 20 Nov 2011 19:14:03 +0000 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4EC6A3A9.3000603@oracle.com> References: <4EC6A3A9.3000603@oracle.com> Message-ID: <4EC9517B.5040808@oracle.com> On 18/11/2011 18:27, Darryl Mocek wrote: > Hello. Please review this patch to fix a serialization issue with > String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize > the class, the equals test will fail in the comparison of what was > serialized with what was deserialized. Webrev, including test, can be > found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev > > Thanks, > Darryl This looks okay to me but I would suggest adding a comment to readResolve, maybe something like "Replaces the de-serialized object" as the causal reader may not know what this method is for. -Alan. From forax at univ-mlv.fr Sun Nov 20 19:39:50 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 20 Nov 2011 20:39:50 +0100 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4EC9517B.5040808@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> Message-ID: <4EC95786.7000605@univ-mlv.fr> On 11/20/2011 08:14 PM, Alan Bateman wrote: > On 18/11/2011 18:27, Darryl Mocek wrote: >> Hello. Please review this patch to fix a serialization issue with >> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >> the class, the equals test will fail in the comparison of what was >> serialized with what was deserialized. Webrev, including test, can >> be found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >> >> Thanks, >> Darryl > This looks okay to me but I would suggest adding a comment to > readResolve, maybe something like "Replaces the de-serialized object" > as the causal reader may not know what this method is for. > > -Alan. Hi Darryl, Hi Alan, additional comments: in the test, you don't need to initialize result to null because you can remove the catch(Exception) block and also you should use == instead of equals for the last check. cheers, R?mi From mike.duigou at oracle.com Sun Nov 20 20:12:54 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 20 Nov 2011 12:12:54 -0800 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4EC95786.7000605@univ-mlv.fr> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> Message-ID: <1481391F-A5BC-4158-ACFF-013CA4888C06@oracle.com> On Nov 20 2011, at 11:39 , R?mi Forax wrote: > On 11/20/2011 08:14 PM, Alan Bateman wrote: >> On 18/11/2011 18:27, Darryl Mocek wrote: >>> Hello. Please review this patch to fix a serialization issue with String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize the class, the equals test will fail in the comparison of what was serialized with what was deserialized. Webrev, including test, can be found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>> >>> Thanks, >>> Darryl >> This looks okay to me but I would suggest adding a comment to readResolve, maybe something like "Replaces the de-serialized object" as the causal reader may not know what this method is for. >> >> -Alan. > > Hi Darryl, Hi Alan, > additional comments: in the test, you don't need to initialize result to null because you can remove the catch(Exception) block > and also you should use == instead of equals for the last check. I would actually use both to make sure that the equals implementation works correctly. Better yet, if (!String.CASE_INSENSITIVE_ORDER.equals(result)) { throw new Exception("Value restored from serial form does not equal original"); } if (!result.equals(String.CASE_INSENSITIVE_ORDER)) { throw new Exception("Value restored from serial form does not equal original"); } if (String.CASE_INSENSITIVE_ORDER != result) { throw new Exception("Value restored from serial form does not match original!"); } I would also add an 'out.close();' after the writeObject to make sure everything is flushed to the ByteArrayOutputStream. Mike From david.holmes at oracle.com Mon Nov 21 00:47:09 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 10:47:09 +1000 Subject: Code Review - 6818464 TEST_BUG: Timeout values in several java/util tests are insufficient In-Reply-To: <4EC68BEB.50609@oracle.com> References: <4EC68BEB.50609@oracle.com> Message-ID: <4EC99F8D.5070908@oracle.com> Gary, On 19/11/2011 2:46 AM, Gary Adams wrote: > I think this change is ready to commit, just need > a sponsor for the last push (Mandy/David?). > > http://cr.openjdk.java.net/~gadams/6818464/ As I've said before the reference to tdThread must be volatile as you are communicating the value from the timer thread to the main thread. So the idiom of using a one-element array instead of a static field is not applicable in this case as you can not declare an array with volatile elements. David From david.holmes at oracle.com Mon Nov 21 00:50:31 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 10:50:31 +1000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4EC688DC.9070407@oracle.com> References: <4EC688DC.9070407@oracle.com> Message-ID: <4EC9A057.6060900@oracle.com> Gary, On 19/11/2011 2:33 AM, Gary Adams wrote: > I think this change is ready to commit, just need > a sponsor for the last push (Mandy/David?). > > http://cr.openjdk.java.net/~gadams/6731620/ With the change of email subject I've lost track of who has reviewed what. Could the Reviewers please respond to this thread indicating their position. I'm one Reviewer. Thanks, David From david.holmes at oracle.com Mon Nov 21 01:04:30 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 11:04:30 +1000 Subject: Code Review - 6860309 TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java In-Reply-To: <4EC68D16.4010002@oracle.com> References: <4EC68D16.4010002@oracle.com> Message-ID: <4EC9A39E.2070604@oracle.com> On 19/11/2011 2:51 AM, Gary Adams wrote: > I think this change is ready to commit, just need > a sponsor for the last push (Mandy/David?). > > http://cr.openjdk.java.net/~gadams/6860309/ Yes this is ready. Do you have jdk8 Author status yet? If so you can prepare the changeset yourself (hg commit - using required jcheck format [1]) then simply point your Committer to your repo from where they can simply issue the "hg push". David [1] http://openjdk.java.net/guide/producingChangeset.html From david.holmes at oracle.com Mon Nov 21 01:07:32 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 11:07:32 +1000 Subject: Code Review - 7084033 TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently In-Reply-To: <4EC68FF1.70406@oracle.com> References: <4EC68FF1.70406@oracle.com> Message-ID: <4EC9A454.9050609@oracle.com> Gary, On 19/11/2011 3:03 AM, Gary Adams wrote: > I think this change is ready to commit, just need > a sponsor for the last push (Mandy/David?). > > http://cr.openjdk.java.net/~gadams/7084033/ This also looks ready. Have you confirmed that this version of the test still fails on a JDK without the fix for 4176355 applied? Thanks, David From david.holmes at oracle.com Mon Nov 21 01:31:37 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 11:31:37 +1000 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4EC95786.7000605@univ-mlv.fr> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> Message-ID: <4EC9A9F9.7040604@oracle.com> On 21/11/2011 5:39 AM, R?mi Forax wrote: > On 11/20/2011 08:14 PM, Alan Bateman wrote: >> On 18/11/2011 18:27, Darryl Mocek wrote: >>> Hello. Please review this patch to fix a serialization issue with >>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>> the class, the equals test will fail in the comparison of what was >>> serialized with what was deserialized. Webrev, including test, can be >>> found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>> >>> Thanks, >>> Darryl >> This looks okay to me but I would suggest adding a comment to >> readResolve, maybe something like "Replaces the de-serialized object" >> as the causal reader may not know what this method is for. >> >> -Alan. > > Hi Darryl, Hi Alan, > additional comments: in the test, you don't need to initialize result to > null because you can remove the catch(Exception) block Related to this I was going to say that if you get an unexpected exception I believe you should simply let it propagate to indicate failure. > and also you should use == instead of equals for the last check. Given equals() is not overridden the two are equivalent. But testing both as Mike suggests would catch any erroneous redefinition of equals() in the future. David ----- > cheers, > R?mi > > From david.holmes at oracle.com Mon Nov 21 01:37:39 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 11:37:39 +1000 Subject: Code Review - 6818464 TEST_BUG: Timeout values in several java/util tests are insufficient In-Reply-To: <4EC99F8D.5070908@oracle.com> References: <4EC68BEB.50609@oracle.com> <4EC99F8D.5070908@oracle.com> Message-ID: <4EC9AB63.4030105@oracle.com> I see this was already pushed. David On 21/11/2011 10:47 AM, David Holmes wrote: > Gary, > > On 19/11/2011 2:46 AM, Gary Adams wrote: >> I think this change is ready to commit, just need >> a sponsor for the last push (Mandy/David?). >> >> http://cr.openjdk.java.net/~gadams/6818464/ > > As I've said before the reference to tdThread must be volatile as you > are communicating the value from the timer thread to the main thread. So > the idiom of using a one-element array instead of a static field is not > applicable in this case as you can not declare an array with volatile > elements. > > David > From david.holmes at oracle.com Mon Nov 21 01:39:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 11:39:23 +1000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4EC9A057.6060900@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> Message-ID: <4EC9ABCB.6050104@oracle.com> Never mind - Alan already tracked down reviews and did push. David On 21/11/2011 10:50 AM, David Holmes wrote: > Gary, > > On 19/11/2011 2:33 AM, Gary Adams wrote: >> I think this change is ready to commit, just need >> a sponsor for the last push (Mandy/David?). >> >> http://cr.openjdk.java.net/~gadams/6731620/ > > With the change of email subject I've lost track of who has reviewed > what. Could the Reviewers please respond to this thread indicating their > position. > > I'm one Reviewer. > > Thanks, > David From david.holmes at oracle.com Mon Nov 21 02:19:03 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 12:19:03 +1000 Subject: Code Review Request for Bug #4802647 In-Reply-To: <4EC7049B.2090605@oracle.com> References: <4EC7049B.2090605@oracle.com> Message-ID: <4EC9B517.2010200@oracle.com> Hi Brandon, On 19/11/2011 11:21 AM, Brandon Passanisi wrote: > Hello core-libs-dev at openjdk.java.net. Please review the following patch > to fix Bug 4802647 (coll) NullPointerException not thrown by > AbstractCollection.retainAll/removeAll: The fix is quite small and I > have included a test program, all of which can be found within the > following webrev: > > http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ The bug report is a little misleading. The bug only exists when the current collection is empty - in which case we skip most of the method body. Otherwise we will generate the NPE when we call c.contains(iter.next()). The CR should be updated to note this. So while your fix is correct, I hate to see good code penalized (explicit null check) to allow bad code to throw exceptions as required. But I don't see a way around it. With regard to the test program - it can be simplified somewhat as unexpected exceptions can just be allowed to propagate and failures to throw can be detected inline: public static void main(String[] args) { // Ensure removeAll(null) throws NullPointerException try { (new NewAbstractCollection<>()).removeAll(null); fail("NullPointerException not thrown for removeAll(null)."); } catch (NullPointerException expected) { } // Ensure retainAll(null) throws NullPointerException try { (new NewAbstractCollection<>()).retainAll(null); fail("NullPointerException not thrown for retainAll(null)."); } catch (NullPointerException expected) { } } Cheers, David > Thanks. From Alan.Bateman at oracle.com Mon Nov 21 10:37:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 10:37:01 +0000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4EC9ABCB.6050104@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> Message-ID: <4ECA29CD.6040406@oracle.com> On 21/11/2011 01:39, David Holmes wrote: > Never mind - Alan already tracked down reviews and did push. Yes, I pushed the three that I thought had been reviewed and thoroughly battered to death. There is a fourth one (test/java/lang/ThreadGroup/Stop.java) that I need to double check who the reviewers are before pushing it. On test/java/util/Timer/KillThread.java then I agree this should be changed as array elements cannot be volatile. I don't think it it will be an issue in practice but we might as well get it done now while the discussion is fresh. -Alan. From gary.adams at oracle.com Mon Nov 21 10:44:22 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 21 Nov 2011 05:44:22 -0500 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA29CD.6040406@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> Message-ID: <4ECA2B86.70707@oracle.com> On 11/21/11 5:37 AM, Alan Bateman wrote: > On 21/11/2011 01:39, David Holmes wrote: >> Never mind - Alan already tracked down reviews and did push. > Yes, I pushed the three that I thought had been reviewed and > thoroughly battered to death. There is a fourth one > (test/java/lang/ThreadGroup/Stop.java) that I need to double check who > the reviewers are before pushing it. > > On test/java/util/Timer/KillThread.java then I agree this should be > changed as array elements cannot be volatile. I don't think it it will > be an issue in practice but we might as well get it done now while the > discussion is fresh. > > -Alan. > > I'll be glad to spin another change here. There were conflicting suggestions on this bug and I thought I took the last comment. From gary.adams at oracle.com Mon Nov 21 12:17:09 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 21 Nov 2011 07:17:09 -0500 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA2B86.70707@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> <4ECA2B86.70707@oracle.com> Message-ID: <4ECA4145.4080902@oracle.com> On 11/21/11 05:44 AM, Gary Adams wrote: > On 11/21/11 5:37 AM, Alan Bateman wrote: >> On 21/11/2011 01:39, David Holmes wrote: >>> Never mind - Alan already tracked down reviews and did push. >> Yes, I pushed the three that I thought had been reviewed and thoroughly >> battered to death. There is a fourth one >> (test/java/lang/ThreadGroup/Stop.java) that I need to double check who the >> reviewers are before pushing it. >> >> On test/java/util/Timer/KillThread.java then I agree this should be changed >> as array elements cannot be volatile. I don't think it it will be an issue in >> practice but we might as well get it done now while the discussion is fresh. >> >> -Alan. >> >> > I'll be glad to spin another change here. > There were conflicting suggestions on > this bug and I thought I took the last > comment. Here's a fresh bug number to handle the volatile revision (pun intended) 7114125 java/util/Timer/KillThread.java should use volatile cross thread variable declaration Here's a fresh webrev for the proposed adjusted fix. http://cr.openjdk.java.net/~gadams/7114125/ From david.holmes at oracle.com Mon Nov 21 12:44:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Nov 2011 22:44:23 +1000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA4145.4080902@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> <4ECA2B86.70707@oracle.com> <4ECA4145.4080902@oracle.com> Message-ID: <4ECA47A7.3090008@oracle.com> On 21/11/2011 10:17 PM, Gary Adams wrote: > On 11/21/11 05:44 AM, Gary Adams wrote: >> On 11/21/11 5:37 AM, Alan Bateman wrote: >>> On 21/11/2011 01:39, David Holmes wrote: >>>> Never mind - Alan already tracked down reviews and did push. >>> Yes, I pushed the three that I thought had been reviewed and >>> thoroughly battered to death. There is a fourth one >>> (test/java/lang/ThreadGroup/Stop.java) that I need to double check >>> who the reviewers are before pushing it. >>> >>> On test/java/util/Timer/KillThread.java then I agree this should be >>> changed as array elements cannot be volatile. I don't think it it >>> will be an issue in practice but we might as well get it done now >>> while the discussion is fresh. >>> >>> -Alan. >>> >>> >> I'll be glad to spin another change here. >> There were conflicting suggestions on >> this bug and I thought I took the last >> comment. > Here's a fresh bug number to handle the volatile revision (pun intended) > 7114125 java/util/Timer/KillThread.java should use volatile cross thread > variable declaration > > Here's a fresh webrev for the proposed adjusted fix. > http://cr.openjdk.java.net/~gadams/7114125/ Looks good to me but can we please have a distinct email thread for the new bug review. Thanks, David > > From Alan.Bateman at oracle.com Mon Nov 21 12:45:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 12:45:39 +0000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA4145.4080902@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> <4ECA2B86.70707@oracle.com> <4ECA4145.4080902@oracle.com> Message-ID: <4ECA47F3.7080409@oracle.com> On 21/11/2011 12:17, Gary Adams wrote: > Here's a fresh bug number to handle the volatile revision (pun intended) > 7114125 java/util/Timer/KillThread.java should use volatile cross > thread variable declaration > > Here's a fresh webrev for the proposed adjusted fix. > http://cr.openjdk.java.net/~gadams/7114125/ > This looks good to me. -Alan From alan.bateman at oracle.com Mon Nov 21 12:54:18 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2011 12:54:18 +0000 Subject: hg: jdk8/tl/jdk: 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Message-ID: <20111121125440.9B5784740C@hg.openjdk.java.net> Changeset: 184578f3e8b9 Author: alanb Date: 2011-11-21 12:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184578f3e8b9 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Reviewed-by: forax, chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/Stop.java From alan.bateman at oracle.com Mon Nov 21 13:00:41 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 21 Nov 2011 13:00:41 +0000 Subject: hg: jdk8/tl/jdk: 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Message-ID: <20111121130051.0B6B34740D@hg.openjdk.java.net> Changeset: 2db942c7eb9c Author: alanb Date: 2011-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2db942c7eb9c 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Reviewed-by: dholmes, alanb Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java From Alan.Bateman at oracle.com Mon Nov 21 13:05:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 13:05:31 +0000 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA47F3.7080409@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> <4ECA2B86.70707@oracle.com> <4ECA4145.4080902@oracle.com> <4ECA47F3.7080409@oracle.com> Message-ID: <4ECA4C9B.5090802@oracle.com> On 21/11/2011 12:45, Alan Bateman wrote: > On 21/11/2011 12:17, Gary Adams wrote: >> Here's a fresh bug number to handle the volatile revision (pun intended) >> 7114125 java/util/Timer/KillThread.java should use volatile cross >> thread variable declaration >> >> Here's a fresh webrev for the proposed adjusted fix. >> http://cr.openjdk.java.net/~gadams/7114125/ >> > This looks good to me. I see David has reviewed this too so I've pushed this change (minus the addition to the @bug tag). I've also pushed your fix to the ThreadGroup/Stop.java test so I think this means we're now caught up on all your contributions to these tests. -Alan. From forax at univ-mlv.fr Mon Nov 21 13:52:39 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 21 Nov 2011 14:52:39 +0100 Subject: Code review - 6731620 TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf In-Reply-To: <4ECA4C9B.5090802@oracle.com> References: <4EC688DC.9070407@oracle.com> <4EC9A057.6060900@oracle.com> <4EC9ABCB.6050104@oracle.com> <4ECA29CD.6040406@oracle.com> <4ECA2B86.70707@oracle.com> <4ECA4145.4080902@oracle.com> <4ECA47F3.7080409@oracle.com> <4ECA4C9B.5090802@oracle.com> Message-ID: <4ECA57A7.2030900@univ-mlv.fr> Le 21/11/2011 14:05, Alan Bateman a ?crit : > On 21/11/2011 12:45, Alan Bateman wrote: >> On 21/11/2011 12:17, Gary Adams wrote: >>> Here's a fresh bug number to handle the volatile revision (pun >>> intended) >>> 7114125 java/util/Timer/KillThread.java should use volatile cross >>> thread variable declaration >>> >>> Here's a fresh webrev for the proposed adjusted fix. >>> http://cr.openjdk.java.net/~gadams/7114125/ >>> >> This looks good to me. > I see David has reviewed this too so I've pushed this change (minus > the addition to the @bug tag). I've also pushed your fix to the > ThreadGroup/Stop.java test so I think this means we're now caught up > on all your contributions to these tests. > > -Alan. Alan, David and Gary, I'm sorry to have proposed to use an array of Thread forgetting that the array was accessed by more than one thread. R?mi From sean.coffey at oracle.com Mon Nov 21 17:19:05 2011 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 21 Nov 2011 17:19:05 +0000 Subject: code review request : JDK 8 : RegistryImpl clean up (7102369) Message-ID: <4ECA8809.2050306@oracle.com> Some clean up of the RMI RegistryImpl class is necessary after late changes made in the last set of update releases. This is a webrev to bring the code into sync with 6uX, 7uX. The java.rmi.server.codebase property no longer needs to be parsed by the registryImpl. webrev : http://cr.openjdk.java.net/~coffeys/webrev.rmi.JDK8/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102369 regards, Sean. From brandon.passanisi at oracle.com Mon Nov 21 18:29:00 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Mon, 21 Nov 2011 10:29:00 -0800 Subject: Code Review Request for Bug #4802647 In-Reply-To: <4EC9B517.2010200@oracle.com> References: <4EC7049B.2090605@oracle.com> <4EC9B517.2010200@oracle.com> Message-ID: <4ECA986C.8090500@oracle.com> Thank you for the review David. I'll make the changes to the test program as you have suggested and I will also update the bug report with the comments you have given. I'll then send out an updated webrev. Just to double-check, when you mention "But I don't see a way around it" in regards to the fix to AbstractCollection.java... it sounds like you agree to keep the change as-is. Is this correct? On 11/20/2011 6:19 PM, David Holmes wrote: > Hi Brandon, > > On 19/11/2011 11:21 AM, Brandon Passanisi wrote: >> Hello core-libs-dev at openjdk.java.net. Please review the following patch >> to fix Bug 4802647 (coll) NullPointerException not thrown by >> AbstractCollection.retainAll/removeAll: The fix is quite small and I >> have included a test program, all of which can be found within the >> following webrev: >> >> http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ > > The bug report is a little misleading. The bug only exists when the > current collection is empty - in which case we skip most of the method > body. Otherwise we will generate the NPE when we call > c.contains(iter.next()). The CR should be updated to note this. > > So while your fix is correct, I hate to see good code penalized > (explicit null check) to allow bad code to throw exceptions as > required. But I don't see a way around it. > > With regard to the test program - it can be simplified somewhat as > unexpected exceptions can just be allowed to propagate and failures to > throw can be detected inline: > > public static void main(String[] args) { > > // Ensure removeAll(null) throws NullPointerException > try { > (new NewAbstractCollection<>()).removeAll(null); > fail("NullPointerException not thrown for > removeAll(null)."); > } catch (NullPointerException expected) { > } > > // Ensure retainAll(null) throws NullPointerException > try { > (new NewAbstractCollection<>()).retainAll(null); > fail("NullPointerException not thrown for > retainAll(null)."); > } catch (NullPointerException expected) { > } > } > > Cheers, > David > >> Thanks. -- Oracle Brandon Passanisi | Principle Member of Technical Staff Oracle Java Standards Conformance Green Oracle Oracle is committed to developing practices and products that help protect the environment From gary.adams at oracle.com Mon Nov 21 19:26:27 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 21 Nov 2011 14:26:27 -0500 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient Message-ID: <4ECAA5E3.6020304@oracle.com> The original complaint about the flakey mutex regression test is that it was failing on slower machines. The delay at the end of the processing is unnecessarily restrictive. Since the test harness will terminate after 120 seconds if the test hangs, the test does not have to terminate more quickly. Here's a propose compromise that allows the service up to 120 seconds to terminate and allows an early exit if the service completes sooner. Alternatively, we could just increase the timeout to the full 120 seconds which will also exit sooner if the service completes earlier. http://cr.openjdk.java.net/~gadams/6736316/ From Alan.Bateman at oracle.com Mon Nov 21 20:02:16 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2011 20:02:16 +0000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECAA5E3.6020304@oracle.com> References: <4ECAA5E3.6020304@oracle.com> Message-ID: <4ECAAE48.7090603@oracle.com> On 21/11/2011 19:26, Gary Adams wrote: > The original complaint about the flakey mutex regression test is > that it was failing on slower machines. The delay at the end of > the processing is unnecessarily restrictive. Since the test harness > will terminate after 120 seconds if the test hangs, the test does > not have to terminate more quickly. > > Here's a propose compromise that allows the service up to 120 seconds > to terminate and allows an early exit if the service completes sooner. > Alternatively, we could just increase the timeout to the full 120 seconds > which will also exit sooner if the service completes earlier. > > http://cr.openjdk.java.net/~gadams/6736316/ > Would it be simpler to just await forever? -Alan. From rob.mckenna at oracle.com Mon Nov 21 20:10:02 2011 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 21 Nov 2011 20:10:02 +0000 Subject: code review request : JDK 7 backport: 7102369 RedirectLimit & Redirect307Test fail intermittently Message-ID: <4ECAB01A.5090503@oracle.com> webrev : http://cr.openjdk.java.net/~robm/7095949/webrev.00/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7095949 -Rob From gary.adams at oracle.com Mon Nov 21 20:26:01 2011 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 21 Nov 2011 15:26:01 -0500 Subject: Code Review - 6957683 TEST_BUG: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing Message-ID: <4ECAB3D9.3040908@oracle.com> Not quite as sure about the internal timeouts in this regression test. Here's a proposed change that cranks up the timeouts. Since the test harness defaults to 2 minutes there's no reason the service termination should timeout more quickly. For the thread startup, I added a countdown latch so the main thread waits til the worker threads have started. Also, after the service termination completes increased the delay to ensure the thread count check will be accurate. http://cr.openjdk.java.net/~gadams/6957683/ From david.holmes at oracle.com Mon Nov 21 23:58:01 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Nov 2011 09:58:01 +1000 Subject: Code Review Request for Bug #4802647 In-Reply-To: <4ECA986C.8090500@oracle.com> References: <4EC7049B.2090605@oracle.com> <4EC9B517.2010200@oracle.com> <4ECA986C.8090500@oracle.com> Message-ID: <4ECAE589.7050401@oracle.com> On 22/11/2011 4:29 AM, Brandon Passanisi wrote: > Thank you for the review David. I'll make the changes to the test > program as you have suggested and I will also update the bug report with > the comments you have given. I'll then send out an updated webrev. Just > to double-check, when you mention "But I don't see a way around it" in > regards to the fix to AbstractCollection.java... it sounds like you > agree to keep the change as-is. Is this correct? Your fix is correct, but I'm not sure that fixing this bug is the best thing to do here. You could easily argue to amend the spec instead. That said, Josh Bloch already indicated (back in 2003) in the CR that this should be fixed. I'd like to hear the opinions of other Collections experts. David > On 11/20/2011 6:19 PM, David Holmes wrote: >> Hi Brandon, >> >> On 19/11/2011 11:21 AM, Brandon Passanisi wrote: >>> Hello core-libs-dev at openjdk.java.net. Please review the following patch >>> to fix Bug 4802647 (coll) NullPointerException not thrown by >>> AbstractCollection.retainAll/removeAll: The fix is quite small and I >>> have included a test program, all of which can be found within the >>> following webrev: >>> >>> http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ >> >> The bug report is a little misleading. The bug only exists when the >> current collection is empty - in which case we skip most of the method >> body. Otherwise we will generate the NPE when we call >> c.contains(iter.next()). The CR should be updated to note this. >> >> So while your fix is correct, I hate to see good code penalized >> (explicit null check) to allow bad code to throw exceptions as >> required. But I don't see a way around it. >> >> With regard to the test program - it can be simplified somewhat as >> unexpected exceptions can just be allowed to propagate and failures to >> throw can be detected inline: >> >> public static void main(String[] args) { >> >> // Ensure removeAll(null) throws NullPointerException >> try { >> (new NewAbstractCollection<>()).removeAll(null); >> fail("NullPointerException not thrown for removeAll(null)."); >> } catch (NullPointerException expected) { >> } >> >> // Ensure retainAll(null) throws NullPointerException >> try { >> (new NewAbstractCollection<>()).retainAll(null); >> fail("NullPointerException not thrown for retainAll(null)."); >> } catch (NullPointerException expected) { >> } >> } >> >> Cheers, >> David >> >>> Thanks. > From brandon.passanisi at oracle.com Tue Nov 22 00:13:01 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Mon, 21 Nov 2011 16:13:01 -0800 Subject: Question regarding java.util.Formatter width Message-ID: <4ECAE90D.9080404@oracle.com> Hello core-libs-dev. I am currently investigating the issues regarding the following bug: http://monaco.sfbay.sun.com/detail.jsf?cr=6178739 I have spent a good amount of time stepping through the simple TestFormat code supplied in the bug report. I noticed some interesting behavior when running the following line in the test which throws the MissingFormatWidthException: System.out.printf("%0.4f\n", 56789.456789); During the execution of this line, the Formatter class appears to treat the "0" not as a width value, which the author of the bug report intended, but rather as a flag value. "0" is a valid flag value indicating that the result will be zero-padded. But, in this case the author of the bug report intended to use the "0" as a width value, citing the Formatter specification text "The optional width is a non-negative decimal integer indicating the minimum number of characters to be written to the output.". Using the "0" in this manner results in a MissingFormatWidthException. Since "0" can be a flag value and also a width value, I am wondering if we have found some sort of gray area in the specification. So, my questions are: 1. Is there possibly some specification text that needs to be used to disallow "0" for a width value? 2. Or, is a value of "0" allowed to be used for both a flag value and width value? 3. If question #2 is true, can "0" be used for both a flag and a width value at the same time? I ask this because the current behavior appears to not work when running the following line: System.out.printf("%00.4f\n", 56789.456789); run: Exception in thread "main" java.util.DuplicateFormatFlagsException: Flags = '0' at java.util.Formatter$Flags.parse(Formatter.java:4186) at java.util.Formatter$FormatSpecifier.flags(Formatter.java:2595) at java.util.Formatter$FormatSpecifier.(Formatter.java:2664) at java.util.Formatter.parse(Formatter.java:2528) at java.util.Formatter.format(Formatter.java:2469) at java.io.PrintStream.format(PrintStream.java:970) at java.io.PrintStream.printf(PrintStream.java:871) at formatterwidthzero.FormatterWidthZero.main(FormatterWidthZero.java:18) Thanks. -- Oracle Brandon Passanisi | Principle Member of Technical Staff Oracle Java Standards Conformance Green Oracle Oracle is committed to developing practices and products that help protect the environment From david.holmes at oracle.com Tue Nov 22 02:08:30 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Nov 2011 12:08:30 +1000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECAA5E3.6020304@oracle.com> References: <4ECAA5E3.6020304@oracle.com> Message-ID: <4ECB041E.3030707@oracle.com> Hi Gary, On 22/11/2011 5:26 AM, Gary Adams wrote: > The original complaint about the flakey mutex regression test is > that it was failing on slower machines. The delay at the end of > the processing is unnecessarily restrictive. Since the test harness > will terminate after 120 seconds if the test hangs, the test does > not have to terminate more quickly. > > Here's a propose compromise that allows the service up to 120 seconds > to terminate and allows an early exit if the service completes sooner. > Alternatively, we could just increase the timeout to the full 120 seconds > which will also exit sooner if the service completes earlier. > > http://cr.openjdk.java.net/~gadams/6736316/ The loop serves no purpose. If you want to wait a maximum of 120 seconds then use a timeout of 120 seconds. As you said, awaitTermination will return earlier if termination completes. I support raising the timeout rather than waiting forever, as these tests should be able to run standalone and in that case they should not hang upon encountering a bug. I'm wary of assuming there is a higher-level test harness involved. Also note that java/util/concurrent tests are generally updated in collaboration with Doug Lea as he also maintains these tests for the jsr166 repository - and runs them. I do have a concern that raising the timeouts/delays too high means that they will no longer be of any use in detecting general unexpected slowdowns. This is a delicate balance between accommodating slow machines and flagging problems with unexpected slowdowns. Maybe there is nothing we can do about that, but I want to flag it. Thanks, David > From david.holmes at oracle.com Tue Nov 22 02:33:10 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Nov 2011 12:33:10 +1000 Subject: Code Review - 6957683 TEST_BUG: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing In-Reply-To: <4ECAB3D9.3040908@oracle.com> References: <4ECAB3D9.3040908@oracle.com> Message-ID: <4ECB09E6.5050208@oracle.com> Gary, On 22/11/2011 6:26 AM, Gary Adams wrote: > Not quite as sure about the internal timeouts in this regression test. > > Here's a proposed change that cranks up the timeouts. Since the test > harness defaults to 2 minutes there's no reason the service termination > should timeout more quickly. For the thread startup, I added a countdown > latch so the main thread waits til the worker threads have started. > > Also, after the service termination completes increased the delay to > ensure the thread count check will be accurate. > > http://cr.openjdk.java.net/~gadams/6957683/ Sorry but I think my initial analysis of this problem was incorrect. The initial test failure reported 3 failed cases: 1 not equal to 0 11 not equal to 10 1 not equal to 0 which corresponded to failures at the marked lines: public static void main(String[] args) throws Throwable { CustomTPE tpe = new CustomTPE(); equal(tpe.getCorePoolSize(), threadCount); equal(countExecutorThreads(), 0); for (int i = 0; i < threadCount; i++) tpe.submit(new Runnable() { public void run() {}}); equal(countExecutorThreads(), threadCount); equal(CustomTask.births.get(), threadCount); tpe.shutdown(); tpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); Thread.sleep(10); /*1*/ equal(countExecutorThreads(), 0); CustomSTPE stpe = new CustomSTPE(); for (int i = 0; i < threadCount; i++) stpe.submit(new Runnable() { public void run() {}}); equal(CustomSTPE.decorations.get(), threadCount); /*2*/ equal(countExecutorThreads(), threadCount); stpe.shutdown(); stpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); Thread.sleep(10); /*3/ equal(countExecutorThreads(), 0); System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); if (failed > 0) throw new Exception("Some tests failed"); } However, I think the failure at /*2*/ is actually seeing the same "extra" thread as reported at /*1*/. It could even be the same thread again at /*3*/ but we have other independent failure cases for /*3*/. When we create the STPE each submit will create and start a worker thread until we reach the core pool size. These worker threads will be immediately visible to the countExecutorThreads() logic because it simply enumerates the ThreadGroup. I was mistakenly thinking that these threads need to actually get a chance to execute to become visible to the counting logic, but that is not the case. Consequently you can elide the change to add the latch and just leave the defensive timeouts on the awaitTermination with the increased sleep delays to give the worker threads a chance to really terminate. Sorry for sending you down the wrong path on this one. David ----- From joe.darcy at oracle.com Tue Nov 22 03:20:00 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Nov 2011 19:20:00 -0800 Subject: StrictMath performance improvement not ported to Math? In-Reply-To: <4EC66BD2.5050205@geomatys.fr> References: <4EC66BD2.5050205@geomatys.fr> Message-ID: <4ECB14E0.9040205@oracle.com> Hello Martin, On 11/18/2011 6:29 AM, Martin Desruisseaux wrote: > Hello all > > On December 1, 2010, "darcy" committed a slight performance > improvement to the StrictMath.min/max methods with floating point > arguments (commit 8aabca72877c). The calls to the > doubleToLongBits(double) method were replaced by calls to the > doubleToRawLongBits(double) method, and similarly for the float type. > Since the call to doubleToLongBits was used only in order to determine > if an argument was negative zero, and since NaN can not map to the > bits pattern of -0.0, the extra cost of collapsing all NaN values to a > single canonical NaN (which is the only difference between > doubleToLongBits and doubleToRawLongBits) was unnecessary. > > However this improvement has not been ported from StrictMath to Math; Good catch and mea culpa! > the more widely-used Math class still invokes the (presumed) slower > doubleToLongBits(double) method. Actually it appears that most Math / > StrictMath method implementations delegate to the other class: some > Math methods delegates to StrictMath (mostly the methods backed by > native code), and some StrictMath methods delegate to Math (mostly the > methods implemented in pure-Java). The min/max methods are an > exception; their implementation is copied in both classes. Maybe this > explain why the code was updated in only one class and not the other? Yes; I may have assumed one of Math.{min, max} and StrictMath.{min, max} delegated to the other since, as you note, that is the usual pattern in these classes. > > In the patch submitted below, I propose the following changes: > > 1) Ported the doubleToLongBits --> doubleToRawLongBits changes from > StrictMath to Math. > > 2) Replaced StrictMath implementations by calls to Math, in order to > reduce the risk that the code of only one class is updated in the future. > > 3) In if statements, replaced: > > (a == 0.0d) && (Double.doubleToLongBits(a) == > negativeZeroDoubleBits) > by > (Double.doubleToLongBits(a) == negativeZeroDoubleBits) > > since the later implies the former. The performance properties of the two versions of the code may differ depending on the frequency of zeros in the input and the cost of the bitwise conversion operation. I'd prefer to leave the code logic as-is in absence of some benchmarking that showed a helpful difference. > > 4) Moved the check for (a != a) from the method beginning to the last > statement, which is tested only if (a <= b) were false rather than > tested unconditionally in every cases. I'm not sure if it make a real > performance difference however. > > Webrev link: http://webrev.geomatys.com/Math/min_max/index.html > > Regards, > > I'd prefer to see a webrev with: * All min/max logic from StrictMath moved into math, including for the integral types int and long * All StrictMath min/max methods delegating to their Math counterpart * Verification all java/lang/Math and java/lang/StrictMath regression tests still pass Thanks, -Joe From neil.richards at ngmr.net Tue Nov 22 09:07:40 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 22 Nov 2011 09:07:40 +0000 Subject: hg: jdk8/tl/jdk: 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Message-ID: <20111122090802.E28404741F@hg.openjdk.java.net> Changeset: 81987765cb81 Author: ngmr Date: 2011-11-11 14:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81987765cb81 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Reviewed-by: chegar, alanb, mduigou, ngmr Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h From chris.hegarty at oracle.com Tue Nov 22 10:07:43 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2011 10:07:43 +0000 Subject: code review request : JDK 7 backport: 7102369 RedirectLimit & Redirect307Test fail intermittently In-Reply-To: <4ECAB01A.5090503@oracle.com> References: <4ECAB01A.5090503@oracle.com> Message-ID: <4ECB746F.6030308@oracle.com> On 11/21/11 08:10 PM, Rob McKenna wrote: > webrev : http://cr.openjdk.java.net/~robm/7095949/webrev.00/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7095949 Looks fine to me. Thanks for porting this to 7u-dev. These intermittent failures are a real pain! -Chris. > > -Rob From neil.richards at ngmr.net Tue Nov 22 11:02:44 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Tue, 22 Nov 2011 11:02:44 +0000 Subject: hg: jdk8/tl/jdk: 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Message-ID: <20111122110306.6DB7647421@hg.openjdk.java.net> Changeset: ee2fa62fb09f Author: ngmr Date: 2011-11-22 09:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee2fa62fb09f 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Reviewed-by: chegar Contributed-by: Neil Richards ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c From neil.richards at ngmr.net Tue Nov 22 11:51:43 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 22 Nov 2011 11:51:43 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode Message-ID: <1321962703.7372.22.camel@chalkhill> Hi all, I've created a webrev [1] to address the problem reported in bug 7094995, where the ClearStaleZipFileInputStreams testcase leaves a lingering GC inducing thread running after the test ends (when run in agentvm mode), as spotted by Alan and mentioned in another conversation [2]. It modifies the testcase so the main thread tells the GcInducingThread to shut down, and waits for it to do so (using Thread.join()) before exiting. I've also converted the testcase's use of ZipFile, ZipOutputStream & FileOutputStream to use ARM (for greater clarity). Please let me know your thoughts on this change, Thanks, Neil [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.00/ [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008251.html -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Tue Nov 22 11:56:22 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2011 11:56:22 +0000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECB041E.3030707@oracle.com> References: <4ECAA5E3.6020304@oracle.com> <4ECB041E.3030707@oracle.com> Message-ID: <4ECB8DE6.40807@oracle.com> On 22/11/2011 02:08, David Holmes wrote: > : > > I support raising the timeout rather than waiting forever, as these > tests should be able to run standalone and in that case they should > not hang upon encountering a bug. I'm wary of assuming there is a > higher-level test harness involved. Also note that > java/util/concurrent tests are generally updated in collaboration with > Doug Lea as he also maintains these tests for the jsr166 repository - > and runs them. > > I do have a concern that raising the timeouts/delays too high means > that they will no longer be of any use in detecting general unexpected > slowdowns. This is a delicate balance between accommodating slow > machines and flagging problems with unexpected slowdowns. Maybe there > is nothing we can do about that, but I want to flag it. I don't think there is much we can do as it's impossible to distinguish a slow down from running on a busy system. Chris - are you keeping on eye on these test changes and whether there will be any sync'ing up needed with Doug's CVS? -Alan. From chris.hegarty at oracle.com Tue Nov 22 12:52:10 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2011 12:52:10 +0000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECB8DE6.40807@oracle.com> References: <4ECAA5E3.6020304@oracle.com> <4ECB041E.3030707@oracle.com> <4ECB8DE6.40807@oracle.com> Message-ID: <4ECB9AFA.3070306@oracle.com> On 11/22/11 11:56 AM, Alan Bateman wrote: > On 22/11/2011 02:08, David Holmes wrote: >> .... > > Chris - are you keeping on eye on these test changes and whether there > will be any sync'ing up needed with Doug's CVS? I've been keepng an eye on these, from a distance ;-) We have in the past pushed a few changes upstream to Doug's CVS. Not that many, and it's not common practice. What we could do here is accumulate all these test changes, then I'll create a patch based on Doug's CVS source and work with him to get it integrated (up stream). That's given that Doug agrees with these changes, but given the level of scrutiny here I hope we can do a sufficient job that Doug would be happy to accept such a patch. Make sense? Otherwise, we will have to work upstream with Doug on each CR and then pull it into OpenJDK (I'm not in favor of this approach). One thing we need to avoid though is getting out of sync with the CVS sources for these test, that would make future integrations a pain! -Chris. > > -Alan. From sean.mullan at oracle.com Tue Nov 22 15:00:27 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 22 Nov 2011 15:00:27 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20111122150129.76BD647427@hg.openjdk.java.net> Changeset: 1945abeb82a0 Author: mullan Date: 2011-11-22 08:58 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1945abeb82a0 7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck Reviewed-by: valeriep ! src/share/classes/java/security/Policy.java Changeset: bb8f19b80557 Author: mullan Date: 2011-11-22 09:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb8f19b80557 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: b4d7020c2a40 Author: mullan Date: 2011-11-22 09:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4d7020c2a40 Merge From gary.adams at oracle.com Tue Nov 22 15:46:31 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 22 Nov 2011 10:46:31 -0500 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECB041E.3030707@oracle.com> References: <4ECAA5E3.6020304@oracle.com> <4ECB041E.3030707@oracle.com> Message-ID: <4ECBC3D7.4010309@oracle.com> Revised webrev is available - removed the loop on termination - increased the original internal termination timeout to 120 seconds. The termination can exit sooner as the services are shutdown. The 120 second timeout is consistent with the jtreg defaults, but can also work standalone as a hang check. http://cr.openjdk.java.net/~gadams/6736316/ It may be best to engage Doug Lea with a batch of updates for the concurrent tests. I agree we need to keep tests in sync. Hopefully, the effort here for slow machine fixes will be worth while upstream. I think it is important to monitor unexpected slowdowns in the system as a whole, but there are better tools for that analysis in the standard performance benchmarks. On 11/21/11 09:08 PM, David Holmes wrote: > Hi Gary, > > On 22/11/2011 5:26 AM, Gary Adams wrote: >> The original complaint about the flakey mutex regression test is >> that it was failing on slower machines. The delay at the end of >> the processing is unnecessarily restrictive. Since the test harness >> will terminate after 120 seconds if the test hangs, the test does >> not have to terminate more quickly. >> >> Here's a propose compromise that allows the service up to 120 seconds >> to terminate and allows an early exit if the service completes sooner. >> Alternatively, we could just increase the timeout to the full 120 seconds >> which will also exit sooner if the service completes earlier. >> >> http://cr.openjdk.java.net/~gadams/6736316/ > > The loop serves no purpose. If you want to wait a maximum of 120 seconds then > use a timeout of 120 seconds. As you said, awaitTermination will return > earlier if termination completes. > > I support raising the timeout rather than waiting forever, as these tests > should be able to run standalone and in that case they should not hang upon > encountering a bug. I'm wary of assuming there is a higher-level test harness > involved. Also note that java/util/concurrent tests are generally updated in > collaboration with Doug Lea as he also maintains these tests for the jsr166 > repository - and runs them. > > I do have a concern that raising the timeouts/delays too high means that they > will no longer be of any use in detecting general unexpected slowdowns. This > is a delicate balance between accommodating slow machines and flagging > problems with unexpected slowdowns. Maybe there is nothing we can do about > that, but I want to flag it. > > Thanks, > David > >> From Alan.Bateman at oracle.com Tue Nov 22 15:49:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2011 15:49:08 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1321962703.7372.22.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> Message-ID: <4ECBC474.5070600@oracle.com> On 22/11/2011 11:51, Neil Richards wrote: > Hi all, > > I've created a webrev [1] to address the problem reported in bug > 7094995, where the ClearStaleZipFileInputStreams testcase leaves a > lingering GC inducing thread running after the test ends (when run in > agentvm mode), as spotted by Alan and mentioned in another conversation > [2]. > > It modifies the testcase so the main thread tells the GcInducingThread > to shut down, and waits for it to do so (using Thread.join()) before > exiting. > > I've also converted the testcase's use of ZipFile, ZipOutputStream& > FileOutputStream to use ARM (for greater clarity). > > Please let me know your thoughts on this change, > Thanks for coming back to this test. It looks okay to me except I would change the notify to notifyAll (I assume you decided to use wait/notify rather than a volatile flag to avoid waiting for the sleep to complete). -Alan. From gary.adams at oracle.com Tue Nov 22 15:57:53 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 22 Nov 2011 10:57:53 -0500 Subject: Code Review - 6957683 TEST_BUG: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing In-Reply-To: <4ECB09E6.5050208@oracle.com> References: <4ECAB3D9.3040908@oracle.com> <4ECB09E6.5050208@oracle.com> Message-ID: <4ECBC681.2040405@oracle.com> Revised webrev is available : - removed the latch logic not required for main to worker thread coordination - increased the timeout to allow service shutdown to 120 seconds (will exit sooner if services finish) - increased delay after service shutdown to ensure thread counts will be updated. http://cr.openjdk.java.net/~gadams/6957683/ On 11/21/11 09:33 PM, David Holmes wrote: > Gary, > > On 22/11/2011 6:26 AM, Gary Adams wrote: >> Not quite as sure about the internal timeouts in this regression test. >> >> Here's a proposed change that cranks up the timeouts. Since the test >> harness defaults to 2 minutes there's no reason the service termination >> should timeout more quickly. For the thread startup, I added a countdown >> latch so the main thread waits til the worker threads have started. >> >> Also, after the service termination completes increased the delay to >> ensure the thread count check will be accurate. >> >> http://cr.openjdk.java.net/~gadams/6957683/ > > Sorry but I think my initial analysis of this problem was incorrect. The > initial test failure reported 3 failed cases: > > 1 not equal to 0 > 11 not equal to 10 > 1 not equal to 0 > > which corresponded to failures at the marked lines: > > public static void main(String[] args) throws Throwable { > CustomTPE tpe = new CustomTPE(); > equal(tpe.getCorePoolSize(), threadCount); > equal(countExecutorThreads(), 0); > for (int i = 0; i < threadCount; i++) > tpe.submit(new Runnable() { public void run() {}}); > equal(countExecutorThreads(), threadCount); > equal(CustomTask.births.get(), threadCount); > tpe.shutdown(); > tpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); > Thread.sleep(10); > /*1*/ equal(countExecutorThreads(), 0); > > CustomSTPE stpe = new CustomSTPE(); > for (int i = 0; i < threadCount; i++) > stpe.submit(new Runnable() { public void run() {}}); > equal(CustomSTPE.decorations.get(), threadCount); > /*2*/ equal(countExecutorThreads(), threadCount); > stpe.shutdown(); > stpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); > Thread.sleep(10); > /*3/ equal(countExecutorThreads(), 0); > > System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); > if (failed > 0) throw new Exception("Some tests failed"); > } > > However, I think the failure at /*2*/ is actually seeing the same "extra" > thread as reported at /*1*/. It could even be the same thread again at /*3*/ > but we have other independent failure cases for /*3*/. > > When we create the STPE each submit will create and start a worker thread > until we reach the core pool size. These worker threads will be immediately > visible to the countExecutorThreads() logic because it simply enumerates the > ThreadGroup. I was mistakenly thinking that these threads need to actually get > a chance to execute to become visible to the counting logic, but that is not > the case. > > Consequently you can elide the change to add the latch and just leave the > defensive timeouts on the awaitTermination with the increased sleep delays to > give the worker threads a chance to really terminate. > > Sorry for sending you down the wrong path on this one. > > David > ----- From neil.richards at ngmr.net Tue Nov 22 16:16:30 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 22 Nov 2011 16:16:30 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECBC474.5070600@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> Message-ID: <1321978590.9940.45.camel@chalkhill> On Tue, 2011-11-22 at 15:49 +0000, Alan Bateman wrote: > On 22/11/2011 11:51, Neil Richards wrote: > > Hi all, > > > > I've created a webrev [1] to address the problem reported in bug > > 7094995, where the ClearStaleZipFileInputStreams testcase leaves a > > lingering GC inducing thread running after the test ends (when run in > > agentvm mode), as spotted by Alan and mentioned in another conversation > > [2]. > > > > It modifies the testcase so the main thread tells the GcInducingThread > > to shut down, and waits for it to do so (using Thread.join()) before > > exiting. > > > > I've also converted the testcase's use of ZipFile, ZipOutputStream& > > FileOutputStream to use ARM (for greater clarity). > > > > Please let me know your thoughts on this change, > > > Thanks for coming back to this test. It looks okay to me except I would > change the notify to notifyAll (I assume you decided to use wait/notify > rather than a volatile flag to avoid waiting for the sleep to complete). > > -Alan. Hi Alan, Thanks for taking a look at this change. You're right, I switched to using wait/notify so the GC'ing thread will stop waiting as soon as it's been told to shut down. Changing the notify to notifyAll is harmless enough, and makes it (even) clearer that the GC'ing thread will definitely be notified by the call. I've uploaded a webrev with this amendment [1]. Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.01/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Tue Nov 22 16:56:11 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2011 16:56:11 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1321978590.9940.45.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> Message-ID: <4ECBD42B.6040704@oracle.com> This change does look good. Not directly related to your changes Neil, and I know we swallow InterruptedException in many tests, but does it make sense to set keepRunning = false if the GcInducingThread is interrupted? jtreg will use Thread.interrupt when trying to "cleanup" after the test has exited. I know in regular execution this should never happen, I'm just thinking about the case where some other bug is lurking, and also what is the general practice to handling InterruptedException in these tests? I really don't like that we ignore it when jtreg uses it for cleanup. -Chris. On 11/22/11 04:16 PM, Neil Richards wrote: > On Tue, 2011-11-22 at 15:49 +0000, Alan Bateman wrote: >> On 22/11/2011 11:51, Neil Richards wrote: >>> Hi all, >>> >>> I've created a webrev [1] to address the problem reported in bug >>> 7094995, where the ClearStaleZipFileInputStreams testcase leaves a >>> lingering GC inducing thread running after the test ends (when run in >>> agentvm mode), as spotted by Alan and mentioned in another conversation >>> [2]. >>> >>> It modifies the testcase so the main thread tells the GcInducingThread >>> to shut down, and waits for it to do so (using Thread.join()) before >>> exiting. >>> >>> I've also converted the testcase's use of ZipFile, ZipOutputStream& >>> FileOutputStream to use ARM (for greater clarity). >>> >>> Please let me know your thoughts on this change, >>> >> Thanks for coming back to this test. It looks okay to me except I would >> change the notify to notifyAll (I assume you decided to use wait/notify >> rather than a volatile flag to avoid waiting for the sleep to complete). >> >> -Alan. > > Hi Alan, > Thanks for taking a look at this change. > > You're right, I switched to using wait/notify so the GC'ing thread will > stop waiting as soon as it's been told to shut down. > > Changing the notify to notifyAll is harmless enough, and makes it (even) > clearer that the GC'ing thread will definitely be notified by the call. > > I've uploaded a webrev with this amendment [1]. > > Regards, Neil > > [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.01/ > From neil.richards at ngmr.net Tue Nov 22 17:22:22 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 22 Nov 2011 17:22:22 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECBD42B.6040704@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> Message-ID: <1321982542.10918.32.camel@chalkhill> On Tue, 2011-11-22 at 16:56 +0000, Chris Hegarty wrote: > This change does look good. > > Not directly related to your changes Neil, and I know we swallow > InterruptedException in many tests, but does it make sense to set > keepRunning = false if the GcInducingThread is interrupted? > > jtreg will use Thread.interrupt when trying to "cleanup" after the test > has exited. I know in regular execution this should never happen, I'm > just thinking about the case where some other bug is lurking, and also > what is the general practice to handling InterruptedException in these > tests? I really don't like that we ignore it when jtreg uses it for cleanup. > > -Chris. Hi Chris, Thanks for your feedback. You make a good point regarding InterruptedException, particularly as this test will hang on "failure" (ie. if the problem it's testing for still exists), so would likely exercise this jtreg "cleanup". (I'm assuming that the cleanup occurs only if a test hasn't finished within some specified time limit). Can you tell me, when jtreg decides to fire an interrupt at a test, has it already concluded that the test has "failed" (or, at least, not "passed") ? If it has reached this conclusion, then I think the change you suggest will be sufficient. Otherwise, I'll also need to record that the GC'ing thread was interrupted, so that the main thread can check this and an exception to ensure it can't be misinterpreted as "passing". Advice on this point gratefully received. Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Tue Nov 22 17:50:45 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 22 Nov 2011 17:50:45 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1321982542.10918.32.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> Message-ID: <1321984245.12261.3.camel@chalkhill> On Tue, 2011-11-22 at 17:22 +0000, Neil Richards wrote: > On Tue, 2011-11-22 at 16:56 +0000, Chris Hegarty wrote: > > This change does look good. > > > > Not directly related to your changes Neil, and I know we swallow > > InterruptedException in many tests, but does it make sense to set > > keepRunning = false if the GcInducingThread is interrupted? > > > > jtreg will use Thread.interrupt when trying to "cleanup" after the test > > has exited. I know in regular execution this should never happen, I'm > > just thinking about the case where some other bug is lurking, and also > > what is the general practice to handling InterruptedException in these > > tests? I really don't like that we ignore it when jtreg uses it for cleanup. > > > > -Chris. > > Hi Chris, > Thanks for your feedback. > > You make a good point regarding InterruptedException, particularly as > this test will hang on "failure" (ie. if the problem it's testing for > still exists), so would likely exercise this jtreg "cleanup". > > (I'm assuming that the cleanup occurs only if a test hasn't finished > within some specified time limit). > > Can you tell me, when jtreg decides to fire an interrupt at a test, has > it already concluded that the test has "failed" (or, at least, not > "passed") ? > > If it has reached this conclusion, then I think the change you suggest > will be sufficient. > > Otherwise, I'll also need to record that the GC'ing thread was > interrupted, so that the main thread can check this and an exception to > ensure it can't be misinterpreted as "passing". > Or, perhaps, convert the InterruptedException to a RuntimeException thrown up and out of the GC'ing thread's run() method. > Advice on this point gratefully received. > > Thanks, Neil > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From darryl.mocek at oracle.com Tue Nov 22 18:32:14 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Tue, 22 Nov 2011 10:32:14 -0800 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4EC9A9F9.7040604@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> Message-ID: <4ECBEAAE.5000305@oracle.com> I've resolved all issues given in the comments. Please review the update. Webrev can be found here: http://cr.openjdk.java.net/~dmocek/5035850/ Thanks, Darryl On 11/20/2011 05:31 PM, David Holmes wrote: > On 21/11/2011 5:39 AM, R?mi Forax wrote: >> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>> Hello. Please review this patch to fix a serialization issue with >>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>> the class, the equals test will fail in the comparison of what was >>>> serialized with what was deserialized. Webrev, including test, can be >>>> found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>> >>>> Thanks, >>>> Darryl >>> This looks okay to me but I would suggest adding a comment to >>> readResolve, maybe something like "Replaces the de-serialized object" >>> as the causal reader may not know what this method is for. >>> >>> -Alan. >> >> Hi Darryl, Hi Alan, >> additional comments: in the test, you don't need to initialize result to >> null because you can remove the catch(Exception) block > > Related to this I was going to say that if you get an unexpected > exception I believe you should simply let it propagate to indicate > failure. > >> and also you should use == instead of equals for the last check. > > Given equals() is not overridden the two are equivalent. But testing > both as Mike suggests would catch any erroneous redefinition of > equals() in the future. > > David > ----- > >> cheers, >> R?mi >> >> From Alan.Bateman at oracle.com Tue Nov 22 18:56:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2011 18:56:39 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1321982542.10918.32.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> Message-ID: <4ECBF067.2090309@oracle.com> On 22/11/2011 17:22, Neil Richards wrote: > : > > Can you tell me, when jtreg decides to fire an interrupt at a test, has > it already concluded that the test has "failed" (or, at least, not > "passed") ? > With othervm (the default) then each test is run in its own VM so the process termination will ensure that everything is cleaned up. With agentvm mode then tests are run sequentially in the same VM (or a pool VMs). In that case then jtreg gives each test its own ThreadGroup. When the test completes then it checks the thread group for any non-daemon threads and interrupts them with the hope that they will terminate in a timely manner. If they don't terminate within a short time then the test fails with an error. With the original test then the thread was a daemon thread which is why we didn't notice a problem. With your updated test then the thread terminates before the test completes so there shouldn't be a problem. Chris's concern comes in in the event that the test doesn't complete (it hangs for example), in which case jtreg will attempt to interrupt the remaining threads before giving up. In agent VM mode this just means the agent (process) will terminate and it spins up a new agent process to replace it. -Alan. From chris.hegarty at oracle.com Tue Nov 22 19:09:36 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2011 19:09:36 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECBF067.2090309@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> <4ECBF067.2090309@oracle.com> Message-ID: <4ECBF370.3040703@oracle.com> On 11/22/11 06:56 PM, Alan Bateman wrote: > On 22/11/2011 17:22, Neil Richards wrote: >> : >> >> Can you tell me, when jtreg decides to fire an interrupt at a test, has >> it already concluded that the test has "failed" (or, at least, not >> "passed") ? >> > With othervm (the default) then each test is run in its own VM so the > process termination will ensure that everything is cleaned up. With > agentvm mode then tests are run sequentially in the same VM (or a pool > VMs). In that case then jtreg gives each test its own ThreadGroup. When > the test completes then it checks the thread group for any non-daemon > threads and interrupts them with the hope that they will terminate in a > timely manner. If they don't terminate within a short time then the test > fails with an error. With the original test then the thread was a daemon > thread which is why we didn't notice a problem. With your updated test > then the thread terminates before the test completes so there shouldn't > be a problem. Chris's concern comes in in the event that the test > doesn't complete (it hangs for example), in which case jtreg will > attempt to interrupt the remaining threads before giving up. In agent VM > mode this just means the agent (process) will terminate and it spins up > a new agent process to replace it. Right, and I was proposing that any threads created by the test be interruptible and be able to terminate in a timely manner. I don't think in this case throwing from the catch block of IE is necessary, just that the thread terminate quickly. It is not relevant to the testing of the original bug. Make sense? -Chris. > > -Alan. > > > > From gary.adams at oracle.com Tue Nov 22 19:47:08 2011 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 22 Nov 2011 14:47:08 -0500 Subject: Code Review - 6776144 java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Message-ID: <4ECBFC3C.9080704@oracle.com> Here's another test that had an assumption that the threads would terminate within a 10 second window. On a busy or slow machine this limit may not be sufficient. Since the jtreg harness uses 120 second default value for terminating a test, the test should not be more restrictive. http://cr.openjdk.java.net/~gadams/6776144/ From chris.hegarty at oracle.com Tue Nov 22 20:03:29 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Nov 2011 20:03:29 +0000 Subject: Code Review - 6776144 java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX In-Reply-To: <4ECBFC3C.9080704@oracle.com> References: <4ECBFC3C.9080704@oracle.com> Message-ID: <4ECC0011.3040805@oracle.com> Looks good to me. Thanks for taking it. -Chris. On 11/22/11 07:47 PM, Gary Adams wrote: > Here's another test that had an assumption that the threads > would terminate within a 10 second window. On a busy or > slow machine this limit may not be sufficient. Since the jtreg > harness uses 120 second default value for terminating a > test, the test should not be more restrictive. > > http://cr.openjdk.java.net/~gadams/6776144/ From martin.desruisseaux at geomatys.fr Tue Nov 22 21:47:13 2011 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 22 Nov 2011 22:47:13 +0100 Subject: StrictMath performance improvement not ported to Math? In-Reply-To: <4ECB14E0.9040205@oracle.com> References: <4EC66BD2.5050205@geomatys.fr> <4ECB14E0.9040205@oracle.com> Message-ID: <4ECC1861.3090604@geomatys.fr> Hello Joe Le 22/11/11 04:20, Joe Darcy a ?crit : >> 3) In if statements, replaced: >> >> (a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits) >> by >> (Double.doubleToLongBits(a) == negativeZeroDoubleBits) >> >> since the later implies the former. > > The performance properties of the two versions of the code may differ > depending on the frequency of zeros in the input and the cost of the bitwise > conversion operation. I'd prefer to leave the code logic as-is in absence of > some benchmarking that showed a helpful difference. I presumed that Double.doubleToRawLongBits(a) - I forgot the "Raw" in my previous post - was very cheap after HotSpot intrinsics (which exist according vmSymbols.hpp). If my old memory from 80286 assembler still have some value, it would have simply be a matter of comparing the value from the same memory address using a different machine instruction. But obviously this is only supposition, today picture is very different and I have no benchmark for confirming or refuting my supposition? > I'd prefer to see a webrev with: > > * All min/max logic from StrictMath moved into math, including for the > integral types int and long > * All StrictMath min/max methods delegating to their Math counterpart Done. I updated the webrev at the same URL: http://webrev.geomatys.com/Math/min_max/index.html The new Math code is a verbatim copy-and-paste from StrictMath, including the formatting. I also made StrictMath.abs methods delegating to their Math counterpart, after making sure that the code was really identical. After this change, the only remaining duplicated code is toDegrees and toRadians. For those two methods, I added a comment saying why StrictMath dos not delegate to Math for them (because the StrictMath methods have the "strictfp" modifier - but this modifier is easy to miss, so a comment may be a worthy safety). > * Verification all java/lang/Math and java/lang/StrictMath regression tests > still pass I quicky tried, but it seems to be a bit tricky for me since I'm on a MacOS machine. Maybe it will be easier when the MacOS port project will be completed... Martin From xueming.shen at oracle.com Tue Nov 22 23:26:58 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 22 Nov 2011 15:26:58 -0800 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Message-ID: <4ECC2FC2.6040503@oracle.com> Hi, java.util.zip.Adler32/CRC32 do not have update method that accepts ByteBuffer. As of JDK7, you have to copy the content of the ByteBuffer into a byte[], then invoke Adler32/CRC32.update() method, which might have significant performance impact for some applications. Here I'm proposing to add two update methods in j.u.z.Adler32 and CRC32 classes respectively to address this issue. Here is the webrev http://cr.openjdk.java.net/~sherman/7109837/webrev Attached is the result of TimeChecksum.java, which also serves as a simple Benchmark. Thanks! Sherman ------------------------------------------------------------------------------------------------------------------------- sherman at sherman-linux:~/Workspace/jdk8_bugfix/test/java/util/zip$ java TimeChecksum ---------- Adler32 ---------- Warmup... 59,535 59,495 59,948 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 13,409,610 2,990,525 ( 77%) 13,196,357 ( 1%) checksum=bd00bd 2 5,808,804 1,664,460 ( 71%) 7,069,931 ( -21%) checksum=19000d3 4 3,009,793 858,267 ( 71%) 3,516,799 ( -16%) checksum=55f01fe 8 1,560,870 508,546 ( 67%) 1,754,650 ( -12%) checksum=11cc03d4 16 792,323 298,697 ( 62%) 931,902 ( -17%) checksum=40fb071b 32 430,367 185,262 ( 56%) 487,747 ( -13%) checksum=ed2b0e1d 64 242,277 123,685 ( 48%) 277,898 ( -14%) checksum=d0601df1 128 147,870 96,570 ( 34%) 164,493 ( -11%) checksum=29d13ac0 256 107,230 80,315 ( 25%) 114,297 ( -6%) checksum=20807ab7 512 85,729 73,765 ( 13%) 90,236 ( -5%) checksum=feb1face 1024 74,593 67,872 ( 9%) 77,241 ( -3%) checksum=7721ffb7 2048 71,558 68,599 ( 4%) 72,673 ( -1%) checksum=717c0800 4096 70,053 64,908 ( 7%) 67,246 ( 4%) checksum=53b5fbe1 8192 62,689 60,908 ( 2%) 62,205 ( 0%) checksum=7ae5e6b3 16384 60,721 59,802 ( 1%) 60,920 ( 0%) checksum=89e1b861 ---------- CRC32 ---------- Warmup... 100,600 101,373 100,795 Length byte[](ns/len) ByteBuffer(direct) ByteBuffer 1 10,929,099 3,562,762 ( 67%) 13,328,815 ( -21%) checksum=10d5102a 2 5,811,664 1,846,604 ( 68%) 6,924,621 ( -19%) checksum=fd7d461a 4 3,048,740 968,395 ( 68%) 3,522,863 ( -15%) checksum=a1ab61ba 8 1,605,356 539,462 ( 66%) 1,778,894 ( -10%) checksum=cdc2506e 16 859,704 318,999 ( 62%) 926,758 ( -7%) checksum=1c3db3a3 32 474,646 216,487 ( 54%) 489,307 ( -3%) checksum=19bbc99e 64 282,917 157,252 ( 44%) 280,958 ( 0%) checksum=df43e0e0 128 195,853 127,730 ( 34%) 164,068 ( 16%) checksum=5fa8c160 256 147,025 116,742 ( 20%) 113,715 ( 22%) checksum=854200ac 512 121,620 108,233 ( 11%) 90,232 ( 25%) checksum=1b6cc88e 1024 110,529 106,890 ( 3%) 77,241 ( 30%) checksum=1456003f 2048 105,115 103,971 ( 1%) 72,716 ( 30%) checksum=187766b0 4096 102,661 103,858 ( -1%) 67,646 ( 34%) checksum=91c34ea3 8192 101,280 103,494 ( -2%) 62,359 ( 38%) checksum=2b8921aa 16384 104,444 105,407 ( 0%) 61,126 ( 41%) checksum=6f921ec0 From stuart.marks at oracle.com Wed Nov 23 00:30:43 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 22 Nov 2011 16:30:43 -0800 Subject: code review request : JDK 8 : RegistryImpl clean up (7102369) In-Reply-To: <4ECA8809.2050306@oracle.com> References: <4ECA8809.2050306@oracle.com> Message-ID: <4ECC3EB3.1040203@oracle.com> Hi Sean, The webrev looks good. Thanks for handling the ports of this change to all the different source bases. s'marks On 11/21/11 9:19 AM, Se?n Coffey wrote: > Some clean up of the RMI RegistryImpl class is necessary after late changes > made in the last set of update releases. > > This is a webrev to bring the code into sync with 6uX, 7uX. > The java.rmi.server.codebase property no longer needs to be parsed by the > registryImpl. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.rmi.JDK8/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102369 > > regards, > Sean. From david.holmes at oracle.com Wed Nov 23 05:57:55 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 15:57:55 +1000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1321962703.7372.22.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> Message-ID: <4ECC8B63.8070000@oracle.com> Hi Neil, On 22/11/2011 9:51 PM, Neil Richards wrote: > I've created a webrev [1] to address the problem reported in bug > 7094995, where the ClearStaleZipFileInputStreams testcase leaves a > lingering GC inducing thread running after the test ends (when run in > agentvm mode), as spotted by Alan and mentioned in another conversation > [2]. > > It modifies the testcase so the main thread tells the GcInducingThread > to shut down, and waits for it to do so (using Thread.join()) before > exiting. As per the discussion from Alan and Chris, I would code it so that interrupt terminates the thread: catch (InterruptedException ie) { return; } > I've also converted the testcase's use of ZipFile, ZipOutputStream& > FileOutputStream to use ARM (for greater clarity). I think proper use of ARM requires that this: 66 try (ZipOutputStream zos = 67 new ZipOutputStream(new FileOutputStream(tempZipFile))) { be written as: try (FileOutputStream fos = new FileOutputStream(tempZipFile); ZipOutputStream zos = new ZipOutputStream(fos)) { Cheers, David > Please let me know your thoughts on this change, > > Thanks, Neil > > [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.00/ > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008251.html > From david.holmes at oracle.com Wed Nov 23 06:27:53 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 16:27:53 +1000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECBC3D7.4010309@oracle.com> References: <4ECAA5E3.6020304@oracle.com> <4ECB041E.3030707@oracle.com> <4ECBC3D7.4010309@oracle.com> Message-ID: <4ECC9269.2080800@oracle.com> Thumbs up from me. David On 23/11/2011 1:46 AM, Gary Adams wrote: > Revised webrev is available > - removed the loop on termination > - increased the original internal termination timeout > to 120 seconds. > > The termination can exit sooner as the services are shutdown. > The 120 second timeout is consistent with the jtreg defaults, > but can also work standalone as a hang check. > > http://cr.openjdk.java.net/~gadams/6736316/ > > It may be best to engage Doug Lea with a batch of updates > for the concurrent tests. I agree we need to keep tests in sync. > Hopefully, the effort here for slow machine fixes will be worth while > upstream. > > I think it is important to monitor unexpected slowdowns in > the system as a whole, but there are better tools for that analysis > in the standard performance benchmarks. > > On 11/21/11 09:08 PM, David Holmes wrote: >> Hi Gary, >> >> On 22/11/2011 5:26 AM, Gary Adams wrote: >>> The original complaint about the flakey mutex regression test is >>> that it was failing on slower machines. The delay at the end of >>> the processing is unnecessarily restrictive. Since the test harness >>> will terminate after 120 seconds if the test hangs, the test does >>> not have to terminate more quickly. >>> >>> Here's a propose compromise that allows the service up to 120 seconds >>> to terminate and allows an early exit if the service completes sooner. >>> Alternatively, we could just increase the timeout to the full 120 >>> seconds >>> which will also exit sooner if the service completes earlier. >>> >>> http://cr.openjdk.java.net/~gadams/6736316/ >> >> The loop serves no purpose. If you want to wait a maximum of 120 >> seconds then use a timeout of 120 seconds. As you said, >> awaitTermination will return earlier if termination completes. >> >> I support raising the timeout rather than waiting forever, as these >> tests should be able to run standalone and in that case they should >> not hang upon encountering a bug. I'm wary of assuming there is a >> higher-level test harness involved. Also note that >> java/util/concurrent tests are generally updated in collaboration with >> Doug Lea as he also maintains these tests for the jsr166 repository - >> and runs them. >> >> I do have a concern that raising the timeouts/delays too high means >> that they will no longer be of any use in detecting general unexpected >> slowdowns. This is a delicate balance between accommodating slow >> machines and flagging problems with unexpected slowdowns. Maybe there >> is nothing we can do about that, but I want to flag it. >> >> Thanks, >> David >> >>> > From david.holmes at oracle.com Wed Nov 23 06:29:24 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 16:29:24 +1000 Subject: Code Review - 6957683 TEST_BUG: test/java/util/concurrent/ThreadPoolExecutor/Custom.java failing In-Reply-To: <4ECBC681.2040405@oracle.com> References: <4ECAB3D9.3040908@oracle.com> <4ECB09E6.5050208@oracle.com> <4ECBC681.2040405@oracle.com> Message-ID: <4ECC92C4.3050006@oracle.com> Thumbs up. Thanks, David ----- On 23/11/2011 1:57 AM, Gary Adams wrote: > Revised webrev is available : > - removed the latch logic not required for main to worker thread > coordination > - increased the timeout to allow service shutdown to 120 seconds > (will exit sooner if services finish) > - increased delay after service shutdown to ensure > thread counts will be updated. > > http://cr.openjdk.java.net/~gadams/6957683/ > > On 11/21/11 09:33 PM, David Holmes wrote: >> Gary, >> >> On 22/11/2011 6:26 AM, Gary Adams wrote: >>> Not quite as sure about the internal timeouts in this regression test. >>> >>> Here's a proposed change that cranks up the timeouts. Since the test >>> harness defaults to 2 minutes there's no reason the service termination >>> should timeout more quickly. For the thread startup, I added a countdown >>> latch so the main thread waits til the worker threads have started. >>> >>> Also, after the service termination completes increased the delay to >>> ensure the thread count check will be accurate. >>> >>> http://cr.openjdk.java.net/~gadams/6957683/ >> >> Sorry but I think my initial analysis of this problem was incorrect. >> The initial test failure reported 3 failed cases: >> >> 1 not equal to 0 >> 11 not equal to 10 >> 1 not equal to 0 >> >> which corresponded to failures at the marked lines: >> >> public static void main(String[] args) throws Throwable { >> CustomTPE tpe = new CustomTPE(); >> equal(tpe.getCorePoolSize(), threadCount); >> equal(countExecutorThreads(), 0); >> for (int i = 0; i < threadCount; i++) >> tpe.submit(new Runnable() { public void run() {}}); >> equal(countExecutorThreads(), threadCount); >> equal(CustomTask.births.get(), threadCount); >> tpe.shutdown(); >> tpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); >> Thread.sleep(10); >> /*1*/ equal(countExecutorThreads(), 0); >> >> CustomSTPE stpe = new CustomSTPE(); >> for (int i = 0; i < threadCount; i++) >> stpe.submit(new Runnable() { public void run() {}}); >> equal(CustomSTPE.decorations.get(), threadCount); >> /*2*/ equal(countExecutorThreads(), threadCount); >> stpe.shutdown(); >> stpe.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS); >> Thread.sleep(10); >> /*3/ equal(countExecutorThreads(), 0); >> >> System.out.printf("%nPassed = %d, failed = %d%n%n", passed, failed); >> if (failed > 0) throw new Exception("Some tests failed"); >> } >> >> However, I think the failure at /*2*/ is actually seeing the same >> "extra" thread as reported at /*1*/. It could even be the same thread >> again at /*3*/ but we have other independent failure cases for /*3*/. >> >> When we create the STPE each submit will create and start a worker >> thread until we reach the core pool size. These worker threads will be >> immediately visible to the countExecutorThreads() logic because it >> simply enumerates the ThreadGroup. I was mistakenly thinking that >> these threads need to actually get a chance to execute to become >> visible to the counting logic, but that is not the case. >> >> Consequently you can elide the change to add the latch and just leave >> the defensive timeouts on the awaitTermination with the increased >> sleep delays to give the worker threads a chance to really terminate. >> >> Sorry for sending you down the wrong path on this one. >> >> David >> ----- > From david.holmes at oracle.com Wed Nov 23 06:39:01 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 16:39:01 +1000 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4ECBEAAE.5000305@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> <4ECBEAAE.5000305@oracle.com> Message-ID: <4ECC9505.2000002@oracle.com> Hi Darryl, On 23/11/2011 4:32 AM, Darryl Mocek wrote: > I've resolved all issues given in the comments. Please review the > update. Webrev can be found here: > http://cr.openjdk.java.net/~dmocek/5035850/ Minor nit: in the test you took Mike's suggestion for the three conditions to check but seem to have overlooked the slightly different wording Mike used in the error messages and have associated the messages with different conditions ie "match" vs "equals" Also wondering if we need to be concerned with closing the streams in case the test runs in samevm or agentvm ? Maybe use try-with-resources. Thanks, David > Thanks, > Darryl > > On 11/20/2011 05:31 PM, David Holmes wrote: >> On 21/11/2011 5:39 AM, R?mi Forax wrote: >>> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>>> Hello. Please review this patch to fix a serialization issue with >>>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>>> the class, the equals test will fail in the comparison of what was >>>>> serialized with what was deserialized. Webrev, including test, can be >>>>> found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>>> >>>>> Thanks, >>>>> Darryl >>>> This looks okay to me but I would suggest adding a comment to >>>> readResolve, maybe something like "Replaces the de-serialized object" >>>> as the causal reader may not know what this method is for. >>>> >>>> -Alan. >>> >>> Hi Darryl, Hi Alan, >>> additional comments: in the test, you don't need to initialize result to >>> null because you can remove the catch(Exception) block >> >> Related to this I was going to say that if you get an unexpected >> exception I believe you should simply let it propagate to indicate >> failure. >> >>> and also you should use == instead of equals for the last check. >> >> Given equals() is not overridden the two are equivalent. But testing >> both as Mike suggests would catch any erroneous redefinition of >> equals() in the future. >> >> David >> ----- >> >>> cheers, >>> R?mi >>> >>> From david.holmes at oracle.com Wed Nov 23 06:40:38 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 16:40:38 +1000 Subject: Code Review - 6776144 java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX In-Reply-To: <4ECC0011.3040805@oracle.com> References: <4ECBFC3C.9080704@oracle.com> <4ECC0011.3040805@oracle.com> Message-ID: <4ECC9566.70200@oracle.com> On 23/11/2011 6:03 AM, Chris Hegarty wrote: > Looks good to me. Thanks for taking it. +1 David > -Chris. > > On 11/22/11 07:47 PM, Gary Adams wrote: >> Here's another test that had an assumption that the threads >> would terminate within a 10 second window. On a busy or >> slow machine this limit may not be sufficient. Since the jtreg >> harness uses 120 second default value for terminating a >> test, the test should not be more restrictive. >> >> http://cr.openjdk.java.net/~gadams/6776144/ From david.holmes at oracle.com Wed Nov 23 06:55:07 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Nov 2011 16:55:07 +1000 Subject: (XS) Request for review: 7109092 - link changes for embedded builds Message-ID: <4ECC98CB.2040805@oracle.com> We need to make an adjustment to the link instructions used for libjava in embedded builds, as defined in Defs-embedded.gmk webrev: http://cr.openjdk.java.net/~dholmes/7109092/webrev/ Summary: system soft-float libraries need not have the level of accuracy required by Java floating-point semantics. On those platforms we have a custom soft-float library to provide the necessary accuracy. This change updated the linker instructions to use that library when linking libjava (really fdlibm is what needs it). The VM has been using a similar library for a while now. I currently have this as a child of jdk8/tl/jdk so would prefer to push there, but can switch to jdk8/build/jdk if the build-dev folks feel strongly about it. Thanks, David From Alan.Bateman at oracle.com Wed Nov 23 08:23:13 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 08:23:13 +0000 Subject: Code Review - 6736316 TEST_BUG: Timeout value in java/util/concurrent/locks/Lock/FlakyMutex.java is insufficient In-Reply-To: <4ECC9269.2080800@oracle.com> References: <4ECAA5E3.6020304@oracle.com> <4ECB041E.3030707@oracle.com> <4ECBC3D7.4010309@oracle.com> <4ECC9269.2080800@oracle.com> Message-ID: <4ECCAD70.8010302@oracle.com> On 23/11/2011 06:27, David Holmes wrote: > Thumbs up from me. > > David > Looks okay to me too although 120s seems way too high, I'd be interested to know how long the termination actually takes on one of these slow machines when it is heavily loaded. -Alan. From Alan.Bateman at oracle.com Wed Nov 23 08:23:15 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 08:23:15 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECBF370.3040703@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> <4ECBF067.2090309@oracle.com> <4ECBF370.3040703@oracle.com> Message-ID: <4ECCAD73.6040408@oracle.com> On 22/11/2011 19:09, Chris Hegarty wrote: > > Right, and I was proposing that any threads created by the test be > interruptible and be able to terminate in a timely manner. > > I don't think in this case throwing from the catch block of IE is > necessary, just that the thread terminate quickly. It is not relevant > to the testing of the original bug. Make sense? > > -Chris. No problem having this thread terminate if interrupted but this should only happen if the test hangs or somehow completes without invoking the shutDown method. In general we can't require that all threads created by tests terminate quickly when interrupted (it's just not feasible). -Alan. From Alan.Bateman at oracle.com Wed Nov 23 10:58:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 10:58:06 +0000 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECC2FC2.6040503@oracle.com> References: <4ECC2FC2.6040503@oracle.com> Message-ID: <4ECCD1BE.5020904@oracle.com> On 22/11/2011 23:26, Xueming Shen wrote: > Hi, > > java.util.zip.Adler32/CRC32 do not have update method that accepts > ByteBuffer. > As of JDK7, you have to copy the content of the ByteBuffer into a > byte[], then > invoke Adler32/CRC32.update() method, which might have significant > performance > impact for some applications. Here I'm proposing to add two update > methods in > j.u.z.Adler32 and CRC32 classes respectively to address this issue. > > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7109837/webrev I think the method descriptions could be do with a bit more polish. For example you could link to the remaining, position, and limit methods. The javadoc could also say that the check sum is not updated if there are no bytes remaining. Neither class specifies how nulls are handled so you could add a statement to the class description to make it clear that NPE is thrown (no need to do this for every method). The test looks good but I don't think it's testing that the buffer position and limit after the calls to update(ByteBuffer). -Alan. From xuelei.fan at oracle.com Wed Nov 23 11:42:22 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 23 Nov 2011 11:42:22 +0000 Subject: hg: jdk8/tl/jdk: 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Message-ID: <20111123114243.2BCA647437@hg.openjdk.java.net> Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82151e860a64 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Summary: also reviewed by Dennis.Gu at oracle.com Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java From chris.hegarty at oracle.com Wed Nov 23 12:31:24 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Nov 2011 12:31:24 +0000 Subject: hg: jdk8/tl/jdk: 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed , fastdebug LINUX Message-ID: <20111123123142.4948947439@hg.openjdk.java.net> Changeset: 7eb0debca9b3 Author: chegar Date: 2011-11-23 12:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7eb0debca9b3 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Reviewed-by: chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/NullThreadName.java From neil.richards at ngmr.net Wed Nov 23 13:29:50 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 23 Nov 2011 13:29:50 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECBF370.3040703@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> <4ECBF067.2090309@oracle.com> <4ECBF370.3040703@oracle.com> Message-ID: <1322054990.15255.49.camel@chalkhill> On Tue, 2011-11-22 at 19:09 +0000, Chris Hegarty wrote: > On 11/22/11 06:56 PM, Alan Bateman wrote: > > On 22/11/2011 17:22, Neil Richards wrote: > >> : > >> > >> Can you tell me, when jtreg decides to fire an interrupt at a test, has > >> it already concluded that the test has "failed" (or, at least, not > >> "passed") ? > >> > > With othervm (the default) then each test is run in its own VM so the > > process termination will ensure that everything is cleaned up. With > > agentvm mode then tests are run sequentially in the same VM (or a pool > > VMs). In that case then jtreg gives each test its own ThreadGroup. When > > the test completes then it checks the thread group for any non-daemon > > threads and interrupts them with the hope that they will terminate in a > > timely manner. If they don't terminate within a short time then the test > > fails with an error. With the original test then the thread was a daemon > > thread which is why we didn't notice a problem. With your updated test > > then the thread terminates before the test completes so there shouldn't > > be a problem. Chris's concern comes in in the event that the test > > doesn't complete (it hangs for example), in which case jtreg will > > attempt to interrupt the remaining threads before giving up. In agent VM > > mode this just means the agent (process) will terminate and it spins up > > a new agent process to replace it. > > Right, and I was proposing that any threads created by the test be > interruptible and be able to terminate in a timely manner. > > I don't think in this case throwing from the catch block of IE is > necessary, just that the thread terminate quickly. It is not relevant to > the testing of the original bug. Make sense? > > -Chris. Thanks for all your guidance on this. I've uploaded another webrev [1], incorporating David's suggested ARM correction (thanks) and Chris' suggested handling of InterruptedException (together a System.out.println(), for clarity). Regards, Neil [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.02/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Wed Nov 23 14:13:25 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 23 Nov 2011 14:13:25 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1322054990.15255.49.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> <4ECBF067.2090309@oracle.com> <4ECBF370.3040703@oracle.com> <1322054990.15255.49.camel@chalkhill> Message-ID: <4ECCFF85.5060402@oracle.com> On 11/23/11 01:29 PM, Neil Richards wrote: > On Tue, 2011-11-22 at 19:09 +0000, Chris Hegarty wrote: >> On 11/22/11 06:56 PM, Alan Bateman wrote: >>> On 22/11/2011 17:22, Neil Richards wrote: >>>> : >>>> >>>> Can you tell me, when jtreg decides to fire an interrupt at a test, has >>>> it already concluded that the test has "failed" (or, at least, not >>>> "passed") ? >>>> >>> With othervm (the default) then each test is run in its own VM so the >>> process termination will ensure that everything is cleaned up. With >>> agentvm mode then tests are run sequentially in the same VM (or a pool >>> VMs). In that case then jtreg gives each test its own ThreadGroup. When >>> the test completes then it checks the thread group for any non-daemon >>> threads and interrupts them with the hope that they will terminate in a >>> timely manner. If they don't terminate within a short time then the test >>> fails with an error. With the original test then the thread was a daemon >>> thread which is why we didn't notice a problem. With your updated test >>> then the thread terminates before the test completes so there shouldn't >>> be a problem. Chris's concern comes in in the event that the test >>> doesn't complete (it hangs for example), in which case jtreg will >>> attempt to interrupt the remaining threads before giving up. In agent VM >>> mode this just means the agent (process) will terminate and it spins up >>> a new agent process to replace it. >> >> Right, and I was proposing that any threads created by the test be >> interruptible and be able to terminate in a timely manner. >> >> I don't think in this case throwing from the catch block of IE is >> necessary, just that the thread terminate quickly. It is not relevant to >> the testing of the original bug. Make sense? >> >> -Chris. > > Thanks for all your guidance on this. > > I've uploaded another webrev [1], incorporating David's suggested ARM > correction (thanks) and Chris' suggested handling of > InterruptedException (together a System.out.println(), for clarity). Looks fine to me. -Chris. > > Regards, Neil > > [1] http://cr.openjdk.java.net/~ngmr/7094995/webrev.02/ > From Alan.Bateman at oracle.com Wed Nov 23 14:46:55 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 14:46:55 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1322054990.15255.49.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECBC474.5070600@oracle.com> <1321978590.9940.45.camel@chalkhill> <4ECBD42B.6040704@oracle.com> <1321982542.10918.32.camel@chalkhill> <4ECBF067.2090309@oracle.com> <4ECBF370.3040703@oracle.com> <1322054990.15255.49.camel@chalkhill> Message-ID: <4ECD075F.10304@oracle.com> On 23/11/2011 13:29, Neil Richards wrote: > : > Thanks for all your guidance on this. > > I've uploaded another webrev [1], incorporating David's suggested ARM > correction (thanks) and Chris' suggested handling of > InterruptedException (together a System.out.println(), for clarity). > Looks fine to me too. I think your original try-with-resources usage was fine too because the ZipOutputStream constructor doesn't throw any exceptions (except perhaps a resource issue in the event that we're out of memory for example). -Alan. From sean.coffey at oracle.com Wed Nov 23 14:54:51 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 23 Nov 2011 14:54:51 +0000 Subject: hg: jdk8/tl/jdk: 7102369: remove java.rmi.server.codebase property parsing from registyimpl; ... Message-ID: <20111123145508.EFCEA4743A@hg.openjdk.java.net> Changeset: d27f0b2f1476 Author: coffeys Date: 2011-11-23 14:55 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d27f0b2f1476 7102369: remove java.rmi.server.codebase property parsing from registyimpl 7094468: rmiregistry clean up Reviewed-by: smarks ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java + test/java/rmi/registry/readTest/readTest.java + test/java/rmi/registry/readTest/readTest.sh + test/java/rmi/registry/readTest/testPkg/Client.java + test/java/rmi/registry/readTest/testPkg/Hello.java + test/java/rmi/registry/readTest/testPkg/Server.java From sebastian.sickelmann at gmx.de Wed Nov 23 04:45:59 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Wed, 23 Nov 2011 05:45:59 +0100 Subject: Answer requested!!! was: Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4EABE0D5.5050802@gmx.de> References: <4E525386.9000207@gmx.de> <4E52758D.2020208@oracle.com> <4E5E8AE3.3070402@gmx.de> <4E5FE753.2010705@oracle.com> <4E606D1D.6050509@gmx.de> <4E613565.1080801@oracle.com> <4E625E14.9060101@gmx.de> <4E67AF3D.2090609@oracle.com> <4E68FFBD.2030601@gmx.de> <4E6A13A2.2020503@gmx.de> <4E74F05D.7090806@gmx.de> <4E7CD5F8.9000501@oracle.com> <4E7DA91C.2000600@gmx.de> <4E81EDE6.9050205@oracle.com> <4E82A437.30907@gmx.de> <4E86073D.9050101@gmx.de> <4E873DA0.5050906@oracle.com> <4E88C03A.90904@gmx.de> <4EA96FB4.7000502@gmx.de> <4EABE0D5.5050802@gmx.de> Message-ID: <4ECC7A87.1030604@gmx.de> It's been a long time ago. Had someone had the time to think about this: Am 29.10.2011 13:17, schrieb Sebastian Sickelmann: > Sorry i linked the wrong webrev for Solution 3. > > Am 27.10.2011 16:50, schrieb Sebastian Sickelmann: >> Some time ago (see below) i ask what would be the right solution to >> refactor >> exception initialization to? >> >> Solution 1: Disallow calls to initCause after creation, if there was an >> exception-cause-functionality in this class before it was introduced >> to Throwable. >> Solution 2: Disallow calls to initCause after creation with in ctor >> which has a cause parameter. >> Solution 3: Disallow calls to initCause after creation, if and only >> if there are ctors >> that allows us to specify the cause at creation time. >> >> >> If i investigated it right:: >> * Solution 1 is used by in the Exceptions in core-libs. >> * Exceptions that had no cause-chain prior to >> Throwable's-cause-chain uses Solution 2. >> * Personally i found Solution 3 is the most intuitive for the users >> >> javax/xml/security- Exceptions had cause-chaining prio to Throwable >> introduces them. jx/x/s-Exceptions are actually not refactored to >> solution 2 like the other exceptions in core-libs that had >> cause-chaining prior to Throwable. >> >> Before my change-request for jx/x/s-Exceptions i changed some in >> core-libs (InternalError and VirtualMachineError) to provide >> exception-chaining. These use Solution 2 like all other exceptions >> that provided exception-chaining after it where introduced by Throwable. >> >> My personal view of this is that i think it may be valueable to >> change all to Solution 3 or at least merge all Solutions to one >> Solution(maybe Solution 2) and get rid of Solution 1. >> I created a webrev[0] for jx/x/s-Exceptions that implements Solution >> 2 (this can be used for all those Exceptions that used Solution 1 too). >> And I created a webrev[1] for jx/x/s-Exceptions that implement >> Solution 3 for comparision. >> >> [0] >> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_4/index.html >> > [1] > http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7011804_6/index.html From joe.darcy at oracle.com Wed Nov 23 16:33:15 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 23 Nov 2011 08:33:15 -0800 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECC8B63.8070000@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECC8B63.8070000@oracle.com> Message-ID: <4ECD204B.2090208@oracle.com> Hello, On 11/22/2011 9:57 PM, David Holmes wrote: > Hi Neil, > > On 22/11/2011 9:51 PM, Neil Richards wrote: >> I've created a webrev [1] to address the problem reported in bug >> 7094995, where the ClearStaleZipFileInputStreams testcase leaves a >> lingering GC inducing thread running after the test ends (when run in >> agentvm mode), as spotted by Alan and mentioned in another conversation >> [2]. >> >> It modifies the testcase so the main thread tells the GcInducingThread >> to shut down, and waits for it to do so (using Thread.join()) before >> exiting. > > As per the discussion from Alan and Chris, I would code it so that > interrupt terminates the thread: > > catch (InterruptedException ie) { > return; > } > >> I've also converted the testcase's use of ZipFile, ZipOutputStream& >> FileOutputStream to use ARM (for greater clarity). > > I think proper use of ARM requires that this: > > 66 try (ZipOutputStream zos = > 67 new ZipOutputStream(new > FileOutputStream(tempZipFile))) { > > be written as: > > try (FileOutputStream fos = new FileOutputStream(tempZipFile); > ZipOutputStream zos = new ZipOutputStream(fos)) { > The more conservative approach is to define one resource variable per logical resource even if the one resource is "wrapped" by the second one, as in the second example. This does close the small window of vulnerability between when the first constructor call ends and the second one completes. However, if that pattern is used, it is important for the close method of the inner resource to be idempotent, as required by the java.io.Closeable type but *not* required by java.lang.AutoCloseable. -Joe From darryl.mocek at oracle.com Wed Nov 23 18:21:52 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Wed, 23 Nov 2011 10:21:52 -0800 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4ECC9505.2000002@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> <4ECBEAAE.5000305@oracle.com> <4ECC9505.2000002@oracle.com> Message-ID: <4ECD39C0.4050506@oracle.com> I've gone back to the try-with-resources implementation in the test (which will close resources), but specifically closing the ObjectOutputStream to ensure flushing of the data. I've also kept the three equals tests and fixed the wording in the Exceptions. Please review: http://cr.openjdk.java.net/~dmocek/5035850/webrev.01 Thanks, Darryl On Tue 22 Nov 2011 10:39:01 PM PST, David Holmes wrote: > Hi Darryl, > > On 23/11/2011 4:32 AM, Darryl Mocek wrote: >> I've resolved all issues given in the comments. Please review the >> update. Webrev can be found here: >> http://cr.openjdk.java.net/~dmocek/5035850/ > > Minor nit: in the test you took Mike's suggestion for the three > conditions to check but seem to have overlooked the slightly different > wording Mike used in the error messages and have associated the > messages with different conditions ie "match" vs "equals" > > Also wondering if we need to be concerned with closing the streams in > case the test runs in samevm or agentvm ? Maybe use try-with-resources. > > Thanks, > David > >> Thanks, >> Darryl >> >> On 11/20/2011 05:31 PM, David Holmes wrote: >>> On 21/11/2011 5:39 AM, R?mi Forax wrote: >>>> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>>>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>>>> Hello. Please review this patch to fix a serialization issue with >>>>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>>>> the class, the equals test will fail in the comparison of what was >>>>>> serialized with what was deserialized. Webrev, including test, >>>>>> can be >>>>>> found here: >>>>>> http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>>>> >>>>>> Thanks, >>>>>> Darryl >>>>> This looks okay to me but I would suggest adding a comment to >>>>> readResolve, maybe something like "Replaces the de-serialized object" >>>>> as the causal reader may not know what this method is for. >>>>> >>>>> -Alan. >>>> >>>> Hi Darryl, Hi Alan, >>>> additional comments: in the test, you don't need to initialize >>>> result to >>>> null because you can remove the catch(Exception) block >>> >>> Related to this I was going to say that if you get an unexpected >>> exception I believe you should simply let it propagate to indicate >>> failure. >>> >>>> and also you should use == instead of equals for the last check. >>> >>> Given equals() is not overridden the two are equivalent. But testing >>> both as Mike suggests would catch any erroneous redefinition of >>> equals() in the future. >>> >>> David >>> ----- >>> >>>> cheers, >>>> R?mi >>>> >>>> From xueming.shen at oracle.com Wed Nov 23 19:39:10 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 23 Nov 2011 11:39:10 -0800 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECCD1BE.5020904@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> Message-ID: <4ECD4BDE.9020208@oracle.com> Thanks Alan. The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/7109837/webrev/ -Sherman On 11/23/2011 02:58 AM, Alan Bateman wrote: > On 22/11/2011 23:26, Xueming Shen wrote: >> Hi, >> >> java.util.zip.Adler32/CRC32 do not have update method that accepts >> ByteBuffer. >> As of JDK7, you have to copy the content of the ByteBuffer into a >> byte[], then >> invoke Adler32/CRC32.update() method, which might have significant >> performance >> impact for some applications. Here I'm proposing to add two update >> methods in >> j.u.z.Adler32 and CRC32 classes respectively to address this issue. >> >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7109837/webrev > I think the method descriptions could be do with a bit more polish. > For example you could link to the remaining, position, and limit > methods. The javadoc could also say that the check sum is not updated > if there are no bytes remaining. Neither class specifies how nulls are > handled so you could add a statement to the class description to make > it clear that NPE is thrown (no need to do this for every method). > > The test looks good but I don't think it's testing that the buffer > position and limit after the calls to update(ByteBuffer). > > -Alan. > > > > > > > > > From brandon.passanisi at oracle.com Wed Nov 23 20:04:49 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Wed, 23 Nov 2011 12:04:49 -0800 Subject: Expected behavior with -esa Message-ID: <4ECD51E1.1010507@oracle.com> I'm currently looking at a bug report: http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue where a simple program was run with the option -esa to enable system assertions. The bug author describes that, in the provided sample code, an AssertionError occurs when the spec says a MissingFormatArgumentException should be thrown. When running the sample program without the -esa option, a MissingFormatArgumentException is thrown. It seems to me that it shouldn't be unexpected to see an AssertionError when -esa is used, instead of the MissingFormatArgumentException. In fact, this behavior appears to not be limited to this particular test case, and can possibly occur with other APIs if an AssertionError is seen before an expected exception. I was hoping to see some sort of explanation in the evaluation or comments section of the bug report, but the bug report was only updated with references about how the bug was filed too late for a release. Can someone clarify if this behavior with -esa is actually a bug? Thanks. From eamonn at mcmanus.net Wed Nov 23 21:22:13 2011 From: eamonn at mcmanus.net (Eamonn McManus) Date: Wed, 23 Nov 2011 13:22:13 -0800 Subject: Expected behavior with -esa In-Reply-To: <4ECD51E1.1010507@oracle.com> References: <4ECD51E1.1010507@oracle.com> Message-ID: Isn't an AssertionError *always* a bug? ?amonn On 23 November 2011 12:04, Brandon Passanisi wrote: > > I'm currently looking at a bug report: http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue where a simple program was run with the option -esa to enable system assertions. ?The bug author describes that, in the provided sample code, an AssertionError occurs when the spec says a MissingFormatArgumentException should be thrown. ?When running the sample program without the -esa option, a MissingFormatArgumentException is thrown. ?It seems to me that it shouldn't be unexpected to see an AssertionError when -esa is used, instead of the MissingFormatArgumentException. ?In fact, this behavior appears to not be limited to this particular test case, and can possibly occur with other APIs if an AssertionError is seen before an expected exception. ?I was hoping to see some sort of explanation in the evaluation or comments section of the bug report, but the bug report was only updated with references about how the bug was filed too late for a release. ?Can someone clarify if this behavior with -esa is actually a bug? > > Thanks. From brandon.passanisi at oracle.com Wed Nov 23 21:57:59 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Wed, 23 Nov 2011 13:57:59 -0800 Subject: Expected behavior with -esa In-Reply-To: References: <4ECD51E1.1010507@oracle.com> Message-ID: <4ECD6C67.3030104@oracle.com> Looking into the issue more, I had incorrectly assumed that the assertion was a pre-condition of the MissingFormatArgumentException because of the differing behavior when -esa is used. After stepping through the code, it is actually unrelated and... is still a bug. On 11/23/2011 1:22 PM, Eamonn McManus wrote: > Isn't an AssertionError *always* a bug? > > ?amonn > > > On 23 November 2011 12:04, Brandon Passanisi > wrote: >> I'm currently looking at a bug report: http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue where a simple program was run with the option -esa to enable system assertions. The bug author describes that, in the provided sample code, an AssertionError occurs when the spec says a MissingFormatArgumentException should be thrown. When running the sample program without the -esa option, a MissingFormatArgumentException is thrown. It seems to me that it shouldn't be unexpected to see an AssertionError when -esa is used, instead of the MissingFormatArgumentException. In fact, this behavior appears to not be limited to this particular test case, and can possibly occur with other APIs if an AssertionError is seen before an expected exception. I was hoping to see some sort of explanation in the evaluation or comments section of the bug report, but the bug report was only updated with references about how the bug was filed too late for a release. Can someone clarify if this behavior with -esa is actually a bug? >> >> Thanks. From Alan.Bateman at oracle.com Wed Nov 23 22:03:45 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2011 22:03:45 +0000 Subject: Expected behavior with -esa In-Reply-To: <4ECD51E1.1010507@oracle.com> References: <4ECD51E1.1010507@oracle.com> Message-ID: <4ECD6DC1.5030005@oracle.com> On 23/11/2011 20:04, Brandon Passanisi wrote: > I'm currently looking at a bug report: > http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an > issue where a simple program was run with the option -esa to enable > system assertions. The bug author describes that, in the provided > sample code, an AssertionError occurs when the spec says a > MissingFormatArgumentException should be thrown. When running the > sample program without the -esa option, a > MissingFormatArgumentException is thrown. It seems to me that it > shouldn't be unexpected to see an AssertionError when -esa is used, > instead of the MissingFormatArgumentException. In fact, this behavior > appears to not be limited to this particular test case, and can > possibly occur with other APIs if an AssertionError is seen before an > expected exception. I was hoping to see some sort of explanation in > the evaluation or comments section of the bug report, but the bug > report was only updated with references about how the bug was filed > too late for a release. Can someone clarify if this behavior with > -esa is actually a bug? > > Thanks. The AssertionError just means it's tripping up on an assert in the code. Looks like it still happens too. -Alan. From stuart.marks at oracle.com Thu Nov 24 00:15:12 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 23 Nov 2011 16:15:12 -0800 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4ECD39C0.4050506@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> <4ECBEAAE.5000305@oracle.com> <4ECC9505.2000002@oracle.com> <4ECD39C0.4050506@oracle.com> Message-ID: <4ECD8C90.3050408@oracle.com> Hi Darryl, I don't want to nickel-and-dime you here but there are a few small things I wanted to mention. - The test is really about String.CaseInsensitiveComparator.readResolve, not String.readResolve. The comments at the top of the test should be updated. - Extra semicolon at line 50. (The following is mainly directed at Mike and David.) I think it's confusing to have the tests for equals() when the implementation today doesn't override equals(). Even if an equals() override were added in the future, this test would have to be rewritten to allow for instances that were equals() but != , so having the equals() checks don't provide any future-proofing either. s'marks On 11/23/11 10:21 AM, Darryl Mocek wrote: > I've gone back to the try-with-resources implementation in the test (which will > close resources), but specifically closing the ObjectOutputStream to ensure > flushing of the data. I've also kept the three equals tests and fixed the > wording in the Exceptions. > > Please review: http://cr.openjdk.java.net/~dmocek/5035850/webrev.01 > > Thanks, > Darryl > > On Tue 22 Nov 2011 10:39:01 PM PST, David Holmes wrote: >> Hi Darryl, >> >> On 23/11/2011 4:32 AM, Darryl Mocek wrote: >>> I've resolved all issues given in the comments. Please review the >>> update. Webrev can be found here: >>> http://cr.openjdk.java.net/~dmocek/5035850/ >> >> Minor nit: in the test you took Mike's suggestion for the three conditions to >> check but seem to have overlooked the slightly different wording Mike used in >> the error messages and have associated the messages with different conditions >> ie "match" vs "equals" >> >> Also wondering if we need to be concerned with closing the streams in case >> the test runs in samevm or agentvm ? Maybe use try-with-resources. >> >> Thanks, >> David >> >>> Thanks, >>> Darryl >>> >>> On 11/20/2011 05:31 PM, David Holmes wrote: >>>> On 21/11/2011 5:39 AM, R?mi Forax wrote: >>>>> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>>>>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>>>>> Hello. Please review this patch to fix a serialization issue with >>>>>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>>>>> the class, the equals test will fail in the comparison of what was >>>>>>> serialized with what was deserialized. Webrev, including test, can be >>>>>>> found here: http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>>>>> >>>>>>> Thanks, >>>>>>> Darryl >>>>>> This looks okay to me but I would suggest adding a comment to >>>>>> readResolve, maybe something like "Replaces the de-serialized object" >>>>>> as the causal reader may not know what this method is for. >>>>>> >>>>>> -Alan. >>>>> >>>>> Hi Darryl, Hi Alan, >>>>> additional comments: in the test, you don't need to initialize result to >>>>> null because you can remove the catch(Exception) block >>>> >>>> Related to this I was going to say that if you get an unexpected >>>> exception I believe you should simply let it propagate to indicate >>>> failure. >>>> >>>>> and also you should use == instead of equals for the last check. >>>> >>>> Given equals() is not overridden the two are equivalent. But testing >>>> both as Mike suggests would catch any erroneous redefinition of >>>> equals() in the future. >>>> >>>> David >>>> ----- >>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> From stuart.marks at oracle.com Thu Nov 24 01:01:24 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 23 Nov 2011 17:01:24 -0800 Subject: Expected behavior with -esa In-Reply-To: <4ECD51E1.1010507@oracle.com> References: <4ECD51E1.1010507@oracle.com> Message-ID: <4ECD9764.8050006@oracle.com> FYI this bug is visible in the open at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5066854 s'marks On 11/23/11 12:04 PM, Brandon Passanisi wrote: > I'm currently looking at a bug report: > http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an issue > where a simple program was run with the option -esa to enable system > assertions. The bug author describes that, in the provided sample code, an > AssertionError occurs when the spec says a MissingFormatArgumentException > should be thrown. When running the sample program without the -esa option, a > MissingFormatArgumentException is thrown. It seems to me that it shouldn't be > unexpected to see an AssertionError when -esa is used, instead of the > MissingFormatArgumentException. In fact, this behavior appears to not be > limited to this particular test case, and can possibly occur with other APIs if > an AssertionError is seen before an expected exception. I was hoping to see > some sort of explanation in the evaluation or comments section of the bug > report, but the bug report was only updated with references about how the bug > was filed too late for a release. Can someone clarify if this behavior with > -esa is actually a bug? > > Thanks. From david.holmes at oracle.com Thu Nov 24 01:22:00 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 11:22:00 +1000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECD204B.2090208@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECC8B63.8070000@oracle.com> <4ECD204B.2090208@oracle.com> Message-ID: <4ECD9C38.5090603@oracle.com> Hi Joe, On 24/11/2011 2:33 AM, Joe Darcy wrote: > On 11/22/2011 9:57 PM, David Holmes wrote: >> On 22/11/2011 9:51 PM, Neil Richards wrote: >>> I've also converted the testcase's use of ZipFile, ZipOutputStream& >>> FileOutputStream to use ARM (for greater clarity). >> >> I think proper use of ARM requires that this: >> >> 66 try (ZipOutputStream zos = >> 67 new ZipOutputStream(new FileOutputStream(tempZipFile))) { >> >> be written as: >> >> try (FileOutputStream fos = new FileOutputStream(tempZipFile); >> ZipOutputStream zos = new ZipOutputStream(fos)) { >> > > The more conservative approach is to define one resource variable per > logical resource even if the one resource is "wrapped" by the second > one, as in the second example. This does close the small window of > vulnerability between when the first constructor call ends and the > second one completes. However, if that pattern is used, it is important > for the close method of the inner resource to be idempotent, as required > by the java.io.Closeable type but *not* required by > java.lang.AutoCloseable. Sorry but I couldn't quite tell what you were recommending there. Is the original code or my change the preferred approach? As I understood it the original code would not close the FileOutputStream if the ZipOutputStream constructor threw an exception. Thanks, David From david.holmes at oracle.com Thu Nov 24 01:59:22 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 11:59:22 +1000 Subject: Expected behavior with -esa In-Reply-To: <4ECD51E1.1010507@oracle.com> References: <4ECD51E1.1010507@oracle.com> Message-ID: <4ECDA4FA.1020104@oracle.com> On 24/11/2011 6:04 AM, Brandon Passanisi wrote: > I'm currently looking at a bug report: > http://monaco.sfbay.sun.com/detail.jsf?cr=5066854 which describes an > issue where a simple program was run with the option -esa to enable > system assertions. The bug author describes that, in the provided sample > code, an AssertionError occurs when the spec says a > MissingFormatArgumentException should be thrown. When running the sample > program without the -esa option, a MissingFormatArgumentException is > thrown. It seems to me that it shouldn't be unexpected to see an > AssertionError when -esa is used, instead of the > MissingFormatArgumentException. In fact, this behavior appears to not be > limited to this particular test case, and can possibly occur with other > APIs if an AssertionError is seen before an expected exception. I was > hoping to see some sort of explanation in the evaluation or comments > section of the bug report, but the bug report was only updated with > references about how the bug was filed too late for a release. Can > someone clarify if this behavior with -esa is actually a bug? I would say it is a bug. Asserts should not be checking conditions that are part of the defined contract for a method. So TCK style tests should still work/pass whether -esa is set or not. David From david.holmes at oracle.com Thu Nov 24 02:07:25 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 12:07:25 +1000 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4ECD8C90.3050408@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> <4ECBEAAE.5000305@oracle.com> <4ECC9505.2000002@oracle.com> <4ECD39C0.4050506@oracle.com> <4ECD8C90.3050408@oracle.com> Message-ID: <4ECDA6DD.9050805@oracle.com> On 24/11/2011 10:15 AM, Stuart Marks wrote: > I don't want to nickel-and-dime you here but there are a few small > things I wanted to mention. > > - The test is really about String.CaseInsensitiveComparator.readResolve, > not String.readResolve. The comments at the top of the test should be > updated. > > - Extra semicolon at line 50. > > (The following is mainly directed at Mike and David.) > > I think it's confusing to have the tests for equals() when the > implementation today doesn't override equals(). Even if an equals() > override were added in the future, this test would have to be rewritten > to allow for instances that were equals() but != , so having the > equals() checks don't provide any future-proofing either. As I said it protects against a future erroneous definition of equals(). In this case an equals() that was not consistent with == would be an erroneous definition. But the only reason to define equals() would be if this were no longer a singleton class, in which case the test would need to be updated anyway. I too am trying not to nickel-and-dime with people's suggestions, but these quick fixes do tend to explode somewhat once a number of pairs of eyes are directed to them. David ----- > s'marks > > On 11/23/11 10:21 AM, Darryl Mocek wrote: >> I've gone back to the try-with-resources implementation in the test >> (which will >> close resources), but specifically closing the ObjectOutputStream to >> ensure >> flushing of the data. I've also kept the three equals tests and fixed the >> wording in the Exceptions. >> >> Please review: http://cr.openjdk.java.net/~dmocek/5035850/webrev.01 >> >> Thanks, >> Darryl >> >> On Tue 22 Nov 2011 10:39:01 PM PST, David Holmes wrote: >>> Hi Darryl, >>> >>> On 23/11/2011 4:32 AM, Darryl Mocek wrote: >>>> I've resolved all issues given in the comments. Please review the >>>> update. Webrev can be found here: >>>> http://cr.openjdk.java.net/~dmocek/5035850/ >>> >>> Minor nit: in the test you took Mike's suggestion for the three >>> conditions to >>> check but seem to have overlooked the slightly different wording Mike >>> used in >>> the error messages and have associated the messages with different >>> conditions >>> ie "match" vs "equals" >>> >>> Also wondering if we need to be concerned with closing the streams in >>> case >>> the test runs in samevm or agentvm ? Maybe use try-with-resources. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Darryl >>>> >>>> On 11/20/2011 05:31 PM, David Holmes wrote: >>>>> On 21/11/2011 5:39 AM, R?mi Forax wrote: >>>>>> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>>>>>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>>>>>> Hello. Please review this patch to fix a serialization issue with >>>>>>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>>>>>> the class, the equals test will fail in the comparison of what was >>>>>>>> serialized with what was deserialized. Webrev, including test, >>>>>>>> can be >>>>>>>> found here: >>>>>>>> http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Darryl >>>>>>> This looks okay to me but I would suggest adding a comment to >>>>>>> readResolve, maybe something like "Replaces the de-serialized >>>>>>> object" >>>>>>> as the causal reader may not know what this method is for. >>>>>>> >>>>>>> -Alan. >>>>>> >>>>>> Hi Darryl, Hi Alan, >>>>>> additional comments: in the test, you don't need to initialize >>>>>> result to >>>>>> null because you can remove the catch(Exception) block >>>>> >>>>> Related to this I was going to say that if you get an unexpected >>>>> exception I believe you should simply let it propagate to indicate >>>>> failure. >>>>> >>>>>> and also you should use == instead of equals for the last check. >>>>> >>>>> Given equals() is not overridden the two are equivalent. But testing >>>>> both as Mike suggests would catch any erroneous redefinition of >>>>> equals() in the future. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> cheers, >>>>>> R?mi >>>>>> >>>>>> From david.holmes at oracle.com Thu Nov 24 02:15:33 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 12:15:33 +1000 Subject: Code Review Request for Bug #5035850 In-Reply-To: <4ECD39C0.4050506@oracle.com> References: <4EC6A3A9.3000603@oracle.com> <4EC9517B.5040808@oracle.com> <4EC95786.7000605@univ-mlv.fr> <4EC9A9F9.7040604@oracle.com> <4ECBEAAE.5000305@oracle.com> <4ECC9505.2000002@oracle.com> <4ECD39C0.4050506@oracle.com> Message-ID: <4ECDA8C5.9000109@oracle.com> On 24/11/2011 4:21 AM, Darryl Mocek wrote: > I've gone back to the try-with-resources implementation in the test > (which will close resources), but specifically closing the > ObjectOutputStream to ensure flushing of the data. I've also kept the > three equals tests and fixed the wording in the Exceptions. > > Please review: http://cr.openjdk.java.net/~dmocek/5035850/webrev.01 Looks okay to me except the test comments as Stuart stated. Really this fix is to ensure that the singleton property of CaseInsensitiveComparator is maintained through serialization/deserialization. David > Thanks, > Darryl > > On Tue 22 Nov 2011 10:39:01 PM PST, David Holmes wrote: >> Hi Darryl, >> >> On 23/11/2011 4:32 AM, Darryl Mocek wrote: >>> I've resolved all issues given in the comments. Please review the >>> update. Webrev can be found here: >>> http://cr.openjdk.java.net/~dmocek/5035850/ >> >> Minor nit: in the test you took Mike's suggestion for the three >> conditions to check but seem to have overlooked the slightly different >> wording Mike used in the error messages and have associated the >> messages with different conditions ie "match" vs "equals" >> >> Also wondering if we need to be concerned with closing the streams in >> case the test runs in samevm or agentvm ? Maybe use try-with-resources. >> >> Thanks, >> David >> >>> Thanks, >>> Darryl >>> >>> On 11/20/2011 05:31 PM, David Holmes wrote: >>>> On 21/11/2011 5:39 AM, R?mi Forax wrote: >>>>> On 11/20/2011 08:14 PM, Alan Bateman wrote: >>>>>> On 18/11/2011 18:27, Darryl Mocek wrote: >>>>>>> Hello. Please review this patch to fix a serialization issue with >>>>>>> String's CASE_INSENSITIVE_ORDER. If you serialize, then deserialize >>>>>>> the class, the equals test will fail in the comparison of what was >>>>>>> serialized with what was deserialized. Webrev, including test, >>>>>>> can be >>>>>>> found here: >>>>>>> http://cr.openjdk.java.net/~sherman/darryl/5035850/webrev >>>>>>> >>>>>>> Thanks, >>>>>>> Darryl >>>>>> This looks okay to me but I would suggest adding a comment to >>>>>> readResolve, maybe something like "Replaces the de-serialized object" >>>>>> as the causal reader may not know what this method is for. >>>>>> >>>>>> -Alan. >>>>> >>>>> Hi Darryl, Hi Alan, >>>>> additional comments: in the test, you don't need to initialize >>>>> result to >>>>> null because you can remove the catch(Exception) block >>>> >>>> Related to this I was going to say that if you get an unexpected >>>> exception I believe you should simply let it propagate to indicate >>>> failure. >>>> >>>>> and also you should use == instead of equals for the last check. >>>> >>>> Given equals() is not overridden the two are equivalent. But testing >>>> both as Mike suggests would catch any erroneous redefinition of >>>> equals() in the future. >>>> >>>> David >>>> ----- >>>> >>>>> cheers, >>>>> R?mi >>>>> >>>>> From Alan.Bateman at oracle.com Thu Nov 24 10:45:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 10:45:01 +0000 Subject: (XS) Request for review: 7109092 - link changes for embedded builds In-Reply-To: <4ECC98CB.2040805@oracle.com> References: <4ECC98CB.2040805@oracle.com> Message-ID: <4ECE202D.4050700@oracle.com> On 23/11/2011 06:55, David Holmes wrote: > We need to make an adjustment to the link instructions used for > libjava in embedded builds, as defined in Defs-embedded.gmk > > webrev: http://cr.openjdk.java.net/~dholmes/7109092/webrev/ > > Summary: system soft-float libraries need not have the level of > accuracy required by Java floating-point semantics. On those platforms > we have a custom soft-float library to provide the necessary accuracy. > This change updated the linker instructions to use that library when > linking libjava (really fdlibm is what needs it). > > The VM has been using a similar library for a while now. > > I currently have this as a child of jdk8/tl/jdk so would prefer to > push there, but can switch to jdk8/build/jdk if the build-dev folks > feel strongly about it. Looks okay to me, as you say, libjvm.so is linked the same way. I don't think it matters which integration forest you use for this, jdk8/tl/jdk is fine. -Alan. From Alan.Bateman at oracle.com Thu Nov 24 11:13:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 11:13:09 +0000 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECD4BDE.9020208@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> Message-ID: <4ECE26C5.1050305@oracle.com> On 23/11/2011 19:39, Xueming Shen wrote: > Thanks Alan. > > The webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/7109837/webrev/ > Minor nit but we should probably use {@code null} instead of null. I think the opening sentence "Updates the Adler32 checksum with the specified ByteBuffer" could be improved, how about: "Updates the checksum with the bytes from the given buffer". Same thing in CRC32. Thanks for adding the test to check the buffer position/limit after the update. One small concern with the test is that it's a bit of a stress test and will run for a long time. What you would think about having a -shortrun option. Look at test/java/util/Arrays/Sorting.java for example where I dialed down Vladimir's test so that it runs quickly in the test runs but is more comprehensively when run without any options. -Alan From neil.richards at ngmr.net Thu Nov 24 11:15:28 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 24 Nov 2011 11:15:28 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECD9C38.5090603@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECC8B63.8070000@oracle.com> <4ECD204B.2090208@oracle.com> <4ECD9C38.5090603@oracle.com> Message-ID: <1322133328.31325.33.camel@chalkhill> On Thu, 2011-11-24 at 11:22 +1000, David Holmes wrote: > Hi Joe, > > On 24/11/2011 2:33 AM, Joe Darcy wrote: > > On 11/22/2011 9:57 PM, David Holmes wrote: > >> On 22/11/2011 9:51 PM, Neil Richards wrote: > >>> I've also converted the testcase's use of ZipFile, ZipOutputStream& > >>> FileOutputStream to use ARM (for greater clarity). > >> > >> I think proper use of ARM requires that this: > >> > >> 66 try (ZipOutputStream zos = > >> 67 new ZipOutputStream(new FileOutputStream(tempZipFile))) { > >> > >> be written as: > >> > >> try (FileOutputStream fos = new FileOutputStream(tempZipFile); > >> ZipOutputStream zos = new ZipOutputStream(fos)) { > >> > > > > The more conservative approach is to define one resource variable per > > logical resource even if the one resource is "wrapped" by the second > > one, as in the second example. This does close the small window of > > vulnerability between when the first constructor call ends and the > > second one completes. However, if that pattern is used, it is important > > for the close method of the inner resource to be idempotent, as required > > by the java.io.Closeable type but *not* required by > > java.lang.AutoCloseable. > > Sorry but I couldn't quite tell what you were recommending there. Is the > original code or my change the preferred approach? As I understood it > the original code would not close the FileOutputStream if the > ZipOutputStream constructor threw an exception. > > Thanks, > David In this instance, I think separating the allocations out into separate statements in the ARM's try is fine, because both FileOutputStream and ZipOutputStream are Closeable, and therefore have idempotent [1] close() methods. (They're obviously also both AutoCloseable, to be used by ARM in the first place). ----- Consider, however, if FileOutputStream were not Closeable, and therefore didn't guarantee the idempotency of its close(). (It might then do something like throw an Exception if close() is called for a second time.) Then the decision to have it auto-closed by ARM would hinge upon whether the call to ZipOutputStream's close() causes a close() call to be made to the (File)OutputStream it holds. If it does, one would not want to use ARM to (also) call the (non-Closeable) FileOutputStream's close(), as it would run the risk of seeing non-idempotent behaviour (eg. an Exception thrown). ----- However, coming back to reality, both objects _are_ Closeable, and so _do_ have idempotent close() methods. Therefore it's both safe to have them both handled by ARM, and (I'd argue) clearer to do so, as it's then clear both objects _do_ get closed, without having to consider the finer details of ZipOutputStream.close(). I believe Joe was defining the considerations needed when making such a modification in the general case. (Joe, please correct me if I misinterpreted this). ----- If I'm correct on this, then I think my suggested change [2] is still good to go. Please speak up if there remain issues with it. Regards, Neil [1] http://en.wikipedia.org/wiki/Idempotence (I confess, I had to look the term up) [2] http://cr.openjdk.java.net/~ngmr/7094995/webrev.02/ -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From Alan.Bateman at oracle.com Thu Nov 24 13:04:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 13:04:51 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <1322133328.31325.33.camel@chalkhill> References: <1321962703.7372.22.camel@chalkhill> <4ECC8B63.8070000@oracle.com> <4ECD204B.2090208@oracle.com> <4ECD9C38.5090603@oracle.com> <1322133328.31325.33.camel@chalkhill> Message-ID: <4ECE40F3.5060507@oracle.com> On 24/11/2011 11:15, Neil Richards wrote: > : > > > If I'm correct on this, then I think my suggested change [2] is still > good to go. > Please speak up if there remain issues with it. > I think you're good to go. -Alan. From maurizio.cimadamore at oracle.com Thu Nov 24 13:40:20 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 24 Nov 2011 13:40:20 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111124134026.77EE747443@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c896d95e7469 7115046: Add AST node for lambda expressions Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: ec59a2ce9114 Author: mcimadamore Date: 2011-11-24 13:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec59a2ce9114 7115049: Add AST node for method references Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java From Alan.Bateman at oracle.com Thu Nov 24 18:03:03 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 18:03:03 +0000 Subject: A method with return type size_t returns negative value In-Reply-To: <4EC21E55.3030106@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> Message-ID: <4ECE86D7.7080000@oracle.com> On 15/11/2011 08:09, Jing Lv wrote: > Hello, > > I search the E:\workspace\openjdk\jdk\src\windows\native but find > nothing similar (please tell me if I miss something), so I suggest we > have a quick fix for now, like: Sorry for the delay getting back to you on this. I think jint would be better than SSIZE_T as jint is how the JVM_Read/Write functions are defined, it matches the parameters and it's what the callers expect too. So here's the webrev with it changed to jint: http://cr.openjdk.java.net/~alanb/7030624/webrev/ I had hoped we would fix this with other clean-up but the other clean-up can wait. I'm still curious how you ran into this as I don't think there is a problem with the generated code (at least not with the Microsoft compilers). -Alan. From Ulf.Zibis at gmx.de Thu Nov 24 19:17:27 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 24 Nov 2011 20:17:27 +0100 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECC2FC2.6040503@oracle.com> References: <4ECC2FC2.6040503@oracle.com> Message-ID: <4ECE9847.6060008@gmx.de> Hi Sherman, I would like a different computation of the percentages: Am 23.11.2011 00:26, schrieb Xueming Shen: > Length byte[](ns/len) ByteBuffer(direct) ByteBuffer > 1 13,409,610 2,990,525 ( 77%) 13,196,357 ( 1%) checksum=bd00bd > 2 5,808,804 1,664,460 ( 71%) 7,069,931 ( -21%) checksum=19000d3 In contrast to 'saved computation time' ... either measured in 'performance gain': 1 13,409,610 2,990,525 (448%) 13,196,357 (102%) checksum=bd00bd 2 5,808,804 1,664,460 (349%) 7,069,931 ( 82%) checksum=19000d3 or measured in 'effective computation time': 1 13,409,610 2,990,525 ( 22%) 13,196,357 ( 98%) checksum=bd00bd 2 5,808,804 1,664,460 ( 29%) 7,069,931 (122%) checksum=19000d3 -Ulf From xueming.shen at oracle.com Thu Nov 24 22:47:46 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 24 Nov 2011 14:47:46 -0800 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECE26C5.1050305@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> <4ECE26C5.1050305@oracle.com> Message-ID: <4ECEC992.3070008@oracle.com> Alan, Ulf, Webrev has been updated accordingly (1) {@code} (2) better wording for opening sentence as suggested (3) added -benhmark option for TimeCheckSum, so only do the benchmark run (with 100000 iteration) when this option is manually specified. Without the option, it runs as a "normal" regression test with iteration 1. (4) to use "ratio" of "time of ByteBuffer: time of byte[]" as http://cr.openjdk.java.net/~sherman/7109837/benchmark http://cr.openjdk.java.net/~sherman/7109837/webrev Thanks, Sherman On 11/24/2011 3:13 AM, Alan Bateman wrote: > On 23/11/2011 19:39, Xueming Shen wrote: >> Thanks Alan. >> >> The webrev has been updated accordingly. >> >> http://cr.openjdk.java.net/~sherman/7109837/webrev/ >> > Minor nit but we should probably use {@code null} instead of > null. > > I think the opening sentence "Updates the Adler32 checksum with the > specified ByteBuffer" could be improved, how about: "Updates the > checksum with the bytes from the given buffer". Same thing in CRC32. > > Thanks for adding the test to check the buffer position/limit after > the update. > > One small concern with the test is that it's a bit of a stress test > and will run for a long time. What you would think about having a > -shortrun option. Look at test/java/util/Arrays/Sorting.java for > example where I dialed down Vladimir's test so that it runs quickly in > the test runs but is more comprehensively when run without any options. > > -Alan > > > > From Ulf.Zibis at gmx.de Fri Nov 25 00:34:16 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 25 Nov 2011 01:34:16 +0100 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECEC992.3070008@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> <4ECE26C5.1050305@oracle.com> <4ECEC992.3070008@oracle.com> Message-ID: <4ECEE288.5010905@gmx.de> Sherman, what is the magic behind, that the adler32 function runs faster on BirectBuffer than on byte[]? Is it GetPrimitiveArrayCritical(env, b, 0) + ReleasePrimitiveArrayCritical(env, b, buf, 0) ? Am 24.11.2011 23:47, schrieb Xueming Shen: > Alan, Ulf, > > Webrev has been updated accordingly > > (1) {@code} > (2) better wording for opening sentence as suggested > (3) added -benhmark option for TimeCheckSum, so only do the benchmark run > (with 100000 iteration) when this option is manually specified. Without the > option, it runs as a "normal" regression test with iteration 1. > (4) to use "ratio" of "time of ByteBuffer: time of byte[]" as > http://cr.openjdk.java.net/~sherman/7109837/benchmark Reads much better :-) > > http://cr.openjdk.java.net/~sherman/7109837/webrev Have you thought about overloading? : void update(DirectBuffer buffer) + void update(ByteBuffer buffer) It would save the instanceof and the cast. At least I would like to see a note in the javadoc, that using DirectBuffer in doubt would be faster than HeapBuffer. Isn't adler32.update(buf.array(), buf.position(), buf.remaining()); buf.flip(); faster than adler32.update(buf); ? Additionally I'm wondering, if there are Buffers which are not direct and dont't have array(). -Ulf From Alan.Bateman at oracle.com Fri Nov 25 10:51:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2011 10:51:08 +0000 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECEC992.3070008@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> <4ECE26C5.1050305@oracle.com> <4ECEC992.3070008@oracle.com> Message-ID: <4ECF731C.5030907@oracle.com> On 24/11/2011 22:47, Xueming Shen wrote: > Alan, Ulf, > > Webrev has been updated accordingly > > (1) {@code} > (2) better wording for opening sentence as suggested > (3) added -benhmark option for TimeCheckSum, so only do the benchmark run > (with 100000 iteration) when this option is manually specified. > Without the > option, it runs as a "normal" regression test with iteration 1. > (4) to use "ratio" of "time of ByteBuffer: time of byte[]" as > http://cr.openjdk.java.net/~sherman/7109837/benchmark > > http://cr.openjdk.java.net/~sherman/7109837/webrev > This looks good to me although I think you've over corrected on the default iteration count in the test. I think it would be fine to have a default of 1000 or 10000, I was really just concerned about >=100000 which would cause the test to run for a long time on a slow system. -Alan. From chris.hegarty at oracle.com Fri Nov 25 12:15:42 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 25 Nov 2011 12:15:42 +0000 Subject: hg: jdk8/tl/jdk: 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Message-ID: <20111125121559.479E247465@hg.openjdk.java.net> Changeset: 387190e1f782 Author: chegar Date: 2011-11-25 10:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/387190e1f782 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java From chris.hegarty at oracle.com Fri Nov 25 16:28:45 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 25 Nov 2011 16:28:45 +0000 Subject: hg: jdk8/tl/jdk: 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Message-ID: <20111125162909.5898247468@hg.openjdk.java.net> Changeset: e5ecbf555679 Author: chegar Date: 2011-11-25 13:46 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5ecbf555679 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar, alanb Contributed-by: sajia at taobao.com ! src/share/classes/sun/nio/ch/SocketAdaptor.java From xueming.shen at oracle.com Fri Nov 25 20:07:11 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 25 Nov 2011 12:07:11 -0800 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECF731C.5030907@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> <4ECE26C5.1050305@oracle.com> <4ECEC992.3070008@oracle.com> <4ECF731C.5030907@oracle.com> Message-ID: <4ECFF56F.7030906@oracle.com> If we run this test as a auto regression test, as we do in jtreg or jprt job, I don't think the "benchmark" number matters and the resulting numbers probably will not be checked (manually), especially 1000 or even 10000 normally might not bring ina reliable benchmark number anyway, so I guess it probably not worth the testing circle to iterate more than 1. But not a big deal for me, if you strongly believe a 10000 iteration result might help some time, I can check in the iteration as 10000. -Sherman On 11/25/2011 2:51 AM, Alan Bateman wrote: > On 24/11/2011 22:47, Xueming Shen wrote: >> Alan, Ulf, >> >> Webrev has been updated accordingly >> >> (1) {@code} >> (2) better wording for opening sentence as suggested >> (3) added -benhmark option for TimeCheckSum, so only do the benchmark >> run >> (with 100000 iteration) when this option is manually specified. >> Without the >> option, it runs as a "normal" regression test with iteration 1. >> (4) to use "ratio" of "time of ByteBuffer: time of byte[]" as >> http://cr.openjdk.java.net/~sherman/7109837/benchmark >> >> http://cr.openjdk.java.net/~sherman/7109837/webrev >> > This looks good to me although I think you've over corrected on the > default iteration count in the test. I think it would be fine to have > a default of 1000 or 10000, I was really just concerned about >=100000 > which would cause the test to run for a long time on a slow system. > > -Alan. > From Alan.Bateman at oracle.com Fri Nov 25 20:31:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2011 20:31:05 +0000 Subject: Codereview request: 7109837 Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer In-Reply-To: <4ECFF56F.7030906@oracle.com> References: <4ECC2FC2.6040503@oracle.com> <4ECCD1BE.5020904@oracle.com> <4ECD4BDE.9020208@oracle.com> <4ECE26C5.1050305@oracle.com> <4ECEC992.3070008@oracle.com> <4ECF731C.5030907@oracle.com> <4ECFF56F.7030906@oracle.com> Message-ID: <4ECFFB09.1060805@oracle.com> On 25/11/2011 20:07, Xueming Shen wrote: > If we run this test as a auto regression test, as we do in jtreg or > jprt job, I don't think the "benchmark" > number matters and the resulting numbers probably will not be checked > (manually), especially 1000 > or even 10000 normally might not bring ina reliable benchmark number > anyway, so I guess it probably > not worth the testing circle to iterate more than 1. But not a big > deal for me, if you strongly believe > a 10000 iteration result might help some time, I can check in the > iteration as 10000. > > -Sherman I don't have a strong opinion on this, one iteration is fine. -Alan From lvjing at linux.vnet.ibm.com Mon Nov 28 08:36:41 2011 From: lvjing at linux.vnet.ibm.com (Jing Lv) Date: Mon, 28 Nov 2011 16:36:41 +0800 Subject: A method with return type size_t returns negative value In-Reply-To: <4EC26A2B.9010106@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> <4EC26A2B.9010106@oracle.com> Message-ID: <4ED34819.3040301@linux.vnet.ibm.com> Hello Alan, I am fine with the fix on the webrev, suppose it would be applied later? I don't remember (as it's been a long time) exactly I found the issue, maybe some code scan or some strong compiler :) (Problem with my mail server so I can only see your mail on website archive) On 2011/11/15 21:33, Alan Bateman wrote: > On 15/11/2011 08:09, Jing Lv wrote: >> Hello, >> >> I search the E:\workspace\openjdk\jdk\src\windows\native but find >> nothing similar (please tell me if I miss something), so I suggest we >> have a quick fix for now, like: > I'm not around this week but I will get back to you next week on this > (as I may have mentioned, I had hoped we would change all of this as > part of other cleanup that includes removing dependencies on the JVM* > functions). > > -Alan. > From weijun.wang at oracle.com Mon Nov 28 10:17:55 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 28 Nov 2011 10:17:55 +0000 Subject: hg: jdk8/tl/jdk: 7115744: Do not call File::deleteOnExit in security tests Message-ID: <20111128101848.4C3E547472@hg.openjdk.java.net> Changeset: 022540b11147 Author: weijun Date: 2011-11-28 18:16 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/022540b11147 7115744: Do not call File::deleteOnExit in security tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java From xuelei.fan at oracle.com Mon Nov 28 10:36:23 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 28 Nov 2011 10:36:23 +0000 Subject: hg: jdk8/tl/jdk: 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Message-ID: <20111128103649.4785447474@hg.openjdk.java.net> Changeset: d1928ae4e0a2 Author: xuelei Date: 2011-11-28 02:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1928ae4e0a2 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java From neil.richards at ngmr.net Mon Nov 28 11:02:08 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 28 Nov 2011 11:02:08 +0000 Subject: hg: jdk8/tl/jdk: 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Message-ID: <20111128110219.E7A3847475@hg.openjdk.java.net> Changeset: 955aae8c1106 Author: ngmr Date: 2011-11-24 11:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/955aae8c1106 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From neil.richards at ngmr.net Mon Nov 28 11:35:41 2011 From: neil.richards at ngmr.net (neil.richards at ngmr.net) Date: Mon, 28 Nov 2011 11:35:41 +0000 Subject: hg: jdk8/tl/jdk: 7094995: Trailing daemon thread causes continuous GC in agentvm mode Message-ID: <20111128113600.0806D47476@hg.openjdk.java.net> Changeset: 6fbd69f8e3ab Author: ngmr Date: 2011-11-18 09:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fbd69f8e3ab 7094995: Trailing daemon thread causes continuous GC in agentvm mode Summary: Shutdown GcInducingThread once test (successfully) finishes Reviewed-by: alanb, chegar, dholmes, darcy Contributed-by: Neil Richards ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java From maurizio.cimadamore at oracle.com Mon Nov 28 16:28:28 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 28 Nov 2011 16:28:28 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20111128162835.25DAC4747A@hg.openjdk.java.net> Changeset: 9448fe783fd2 Author: mcimadamore Date: 2011-11-28 15:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9448fe783fd2 7115050: Add parser support for lambda expressions Summary: Add support for parsing lambda expressions to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/LambdaNotSupported.java + test/tools/javac/diags/examples/NotAStatement.java ! test/tools/javac/generics/rare/6665356/T6665356.out + test/tools/javac/lambda/LambdaParserTest.java Changeset: 3343b22e2761 Author: mcimadamore Date: 2011-11-28 16:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3343b22e2761 7115052: Add parser support for method references Summary: Add support for parsing method references to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/MethodReferencesNotSupported.java + test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out From neil.richards at ngmr.net Mon Nov 28 17:12:27 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 28 Nov 2011 17:12:27 +0000 Subject: Request for Review: 7094995: test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java causes continuous GC in agentvm mode In-Reply-To: <4ECE40F3.5060507@oracle.com> References: <1321962703.7372.22.camel@chalkhill> <4ECC8B63.8070000@oracle.com> <4ECD204B.2090208@oracle.com> <4ECD9C38.5090603@oracle.com> <1322133328.31325.33.camel@chalkhill> <4ECE40F3.5060507@oracle.com> Message-ID: <1322500347.6281.5.camel@chalkhill> On Thu, 2011-11-24 at 13:04 +0000, Alan Bateman wrote: > On 24/11/2011 11:15, Neil Richards wrote: > > : > > > > > > If I'm correct on this, then I think my suggested change [2] is still > > good to go. > > Please speak up if there remain issues with it. > > > I think you're good to go. > > -Alan. Thanks to all for their help in reviewing this change. I've now pushed up the change [1]. Regards, Neil [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6fbd69f8e3ab -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From kelly.ohair at oracle.com Mon Nov 28 18:12:27 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 28 Nov 2011 10:12:27 -0800 Subject: (XS) Request for review: 7109092 - link changes for embedded builds In-Reply-To: <4ECC98CB.2040805@oracle.com> References: <4ECC98CB.2040805@oracle.com> Message-ID: Looks ok to me. -kto On Nov 22, 2011, at 10:55 PM, David Holmes wrote: > We need to make an adjustment to the link instructions used for libjava in embedded builds, as defined in Defs-embedded.gmk > > webrev: http://cr.openjdk.java.net/~dholmes/7109092/webrev/ > > Summary: system soft-float libraries need not have the level of accuracy required by Java floating-point semantics. On those platforms we have a custom soft-float library to provide the necessary accuracy. This change updated the linker instructions to use that library when linking libjava (really fdlibm is what needs it). > > The VM has been using a similar library for a while now. > > I currently have this as a child of jdk8/tl/jdk so would prefer to push there, but can switch to jdk8/build/jdk if the build-dev folks feel strongly about it. > > Thanks, > David From xueming.shen at oracle.com Mon Nov 28 22:06:50 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 28 Nov 2011 14:06:50 -0800 Subject: zlib 1.2.3 -> 1.2.5 Message-ID: <4ED405FA.3010204@oracle.com> Hi, Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 for JDK8 http://cr.openjdk.java.net/~sherman/7110149/webrev The changes to the original zlib source code (other than the copyright attachment) is at http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html For you reference, the 1.2.3 upgrade webrev can be found at http://cr.openjdk.java.net/~sherman/zlib123/webrev Thanks, Sherman From Ulf.Zibis at gmx.de Mon Nov 28 22:47:08 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 28 Nov 2011 23:47:08 +0100 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED405FA.3010204@oracle.com> References: <4ED405FA.3010204@oracle.com> Message-ID: <4ED40F6C.4060105@gmx.de> Would zlib 1.2.3 remain in JDK8 repo alongside 1.2.5 ? -Ulf Am 28.11.2011 23:06, schrieb Xueming Shen: > Hi, > > Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 for JDK8 > > http://cr.openjdk.java.net/~sherman/7110149/webrev > > The changes to the original zlib source code (other than the copyright attachment) > is at > > http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html > > > For you reference, the 1.2.3 upgrade webrev can be found at > > http://cr.openjdk.java.net/~sherman/zlib123/webrev > > Thanks, > Sherman > From xueming.shen at oracle.com Mon Nov 28 23:49:53 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 28 Nov 2011 15:49:53 -0800 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED40F6C.4060105@gmx.de> References: <4ED405FA.3010204@oracle.com> <4ED40F6C.4060105@gmx.de> Message-ID: <4ED41E21.6000805@oracle.com> The zlib-1.2.3 folder will be deleted. I did not list them in the webrev. I should have mentioned in the request. -Sherman On 11/28/2011 2:47 PM, Ulf Zibis wrote: > Would zlib 1.2.3 remain in JDK8 repo alongside 1.2.5 ? > > -Ulf > > Am 28.11.2011 23:06, schrieb Xueming Shen: >> Hi, >> >> Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 >> for JDK8 >> >> http://cr.openjdk.java.net/~sherman/7110149/webrev >> >> The changes to the original zlib source code (other than the >> copyright attachment) >> is at >> >> http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html >> >> >> For you reference, the 1.2.3 upgrade webrev can be found at >> >> http://cr.openjdk.java.net/~sherman/zlib123/webrev >> >> Thanks, >> Sherman >> From youdwei at linux.vnet.ibm.com Tue Nov 29 01:55:24 2011 From: youdwei at linux.vnet.ibm.com (Deven) Date: Tue, 29 Nov 2011 09:55:24 +0800 Subject: Add Look&Feel support for AIX platform In-Reply-To: <1319123400.9882.48.camel@chalkhill> References: <1319123400.9882.48.camel@chalkhill> Message-ID: <4ED43B8C.10808@linux.vnet.ibm.com> On 10/20/2011 11:10 PM, Neil Richards wrote: > On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote: >> Hi all, >> >> >> This is a simple patch to add LookAndFeel support for AIX platform >> to help bring >> up GUI application. >> >> >> This is part of the series of AIX patches. >> -- >> Best Regards, >> Sean Chou >> >> > For ease of review, I've uploaded this suggested fix as a webrev [1]. > > The change looks good to me. > > Regards, Neil > > [1] http://cr.openjdk.java.net/~ngmr/ojdk-167/webrev.00/index.html Hello, any more comments on this topic? From david.holmes at oracle.com Tue Nov 29 05:27:43 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 29 Nov 2011 05:27:43 +0000 Subject: hg: jdk8/tl/jdk: 7109092: Wrong computation results with double at armsflt Message-ID: <20111129052802.D0F0647488@hg.openjdk.java.net> Changeset: cf47846165f4 Author: dholmes Date: 2011-11-29 00:26 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf47846165f4 7109092: Wrong computation results with double at armsflt Summary: need to link to custom soft-float library with required FP accuracy Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk From Alan.Bateman at oracle.com Tue Nov 29 10:23:28 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Nov 2011 10:23:28 +0000 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED405FA.3010204@oracle.com> References: <4ED405FA.3010204@oracle.com> Message-ID: <4ED4B2A0.6050601@oracle.com> On 28/11/2011 22:06, Xueming Shen wrote: > Hi, > > Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 > for JDK8 > > http://cr.openjdk.java.net/~sherman/7110149/webrev > > The changes to the original zlib source code (other than the copyright > attachment) > is at > > http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html > > > For you reference, the 1.2.3 upgrade webrev can be found at > > http://cr.openjdk.java.net/~sherman/zlib123/webrev > > Thanks, > Sherman Thanks for doing this, the upgrade looks fine to me (assuming that zlib1.2.3 is deleted). One concern about the test is that it would appear to be long running. I grabbed it and tried it on my system with zlib1.2.3 and it took about 25s, and just over 1m on a much older/slower machine. Maybe the innermost loop could be dialed down, say to 5. It might be best to drop the /timeout=1000 as the right way to increase the timeout on really slow machines is to run with -timeoutFactor:N. Minor comment on the test is that new Random(new Date().getTime()).nextBytes(dataIn) is a bit odd. Also might be nicer if check didn't declare that its throws Throwable. When we talked about the zlib version here (I think back in February) we talked about having the option to use the system's zip library where appropriate. Have you given this any thought recently? -Alan. From Ulf.Zibis at gmx.de Tue Nov 29 14:05:47 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 29 Nov 2011 15:05:47 +0100 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED4B2A0.6050601@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> Message-ID: <4ED4E6BB.1080908@gmx.de> Am 29.11.2011 11:23, schrieb Alan Bateman: > When we talked about the zlib version here (I think back in February) we talked about having the > option to use the system's zip library where appropriate. Have you given this any thought recently? +1 Ulf From sebastian.sickelmann at gmx.de Tue Nov 29 14:33:52 2011 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 29 Nov 2011 15:33:52 +0100 Subject: Last Change for comment on 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException Message-ID: <4ED4ED50.4050102@gmx.de> Hi, I started some cleanup work a while ago and we got into short discussions while cleaning-up javax.xml.crypto. Unfortunately i got no relay for a long time. Tried to get some comments on 2011-10-27 [1] and 2011-11-23 [2] but nobody reacted. Maybe i have done something wrong, maybe i have bothered some of you with my requests for comments, maybe i lost some email that was send to me(which i tripple checked), but if the cleanup exception-chains is not worth any discussion, then say it and i stop and work on other things. Don't get me wrong, i want to contribute and the cleanup was a nice starting job but I don't have to do this cleanup work. I suggested it and i want to "stay to my words", and i don't like open issues in my inbox. So let me know if someone is interested in the cleanups and willing to discuss some bigger changes or i will delete this task from my inbox. -- Sebastian [core-libs-dev] [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/008023.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008355.html [security-dev] [1] http://mail.openjdk.java.net/pipermail/security-dev/2011-October/003972.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2011-November/004105.html From sean.mullan at oracle.com Tue Nov 29 14:55:57 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Nov 2011 09:55:57 -0500 Subject: Last Change for comment on 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException In-Reply-To: <4ED4ED50.4050102@gmx.de> References: <4ED4ED50.4050102@gmx.de> Message-ID: <4ED4F27D.1040707@oracle.com> Sorry, I have been very busy with some other things in the past few weeks, but I will try to find some time to look at your latest webrev this week. --Sean On 11/29/11 9:33 AM, Sebastian Sickelmann wrote: > Hi, > > I started some cleanup work a while ago and we got into short > discussions while cleaning-up javax.xml.crypto. > > Unfortunately i got no relay for a long time. Tried to get some comments > on 2011-10-27 [1] and 2011-11-23 [2] but nobody reacted. > > Maybe i have done something wrong, maybe i have bothered some of you > with my requests for comments, maybe i lost some email that was send to > me(which i tripple checked), but if the cleanup exception-chains is not > worth any discussion, then say it and i stop and work on other things. > > Don't get me wrong, i want to contribute and the cleanup was a nice > starting job but I don't have to do this cleanup work. > I suggested it and i want to "stay to my words", and i don't like open > issues in my inbox. > > So let me know if someone is interested in the cleanups and willing to > discuss some bigger changes or i will delete this task from my inbox. > > -- Sebastian > > [core-libs-dev] > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/008023.html > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008355.html > [security-dev] > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2011-October/003972.html > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2011-November/004105.html From Alan.Bateman at oracle.com Tue Nov 29 16:10:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Nov 2011 16:10:19 +0000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Message-ID: <4ED503EB.6000708@oracle.com> I don't have time on Thursday to get involved in the warnings fest [1]. However I would like to contribute something and to that end the following webrev proposes changes to eliminate the warnings from several classes including java.rmi.**, the serialization classes, and several core classes: http://cr.openjdk.java.net/~alanb/7116404/webrev/ The changes are mostly trivial, and mostly to raw type usages. One tricky one ObjectInputStream.readEnum where I had to use a raw type (Maurizio and I chatted about this one and there doesn't seem to be a better workaround). There is one non-warnings change in java.rmi.server.LogStream where I replaced a usage of legacy Hashtable with a HashMap. -Alan. [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html From Alan.Bateman at oracle.com Tue Nov 29 16:19:54 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Nov 2011 16:19:54 +0000 Subject: A method with return type size_t returns negative value In-Reply-To: <4ED34819.3040301@linux.vnet.ibm.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> <4EC26A2B.9010106@oracle.com> <4ED34819.3040301@linux.vnet.ibm.com> Message-ID: <4ED5062A.5020007@oracle.com> On 28/11/2011 08:36, Jing Lv wrote: > Hello Alan, > > I am fine with the fix on the webrev, suppose it would be applied > later? > I don't remember (as it's been a long time) exactly I found the > issue, maybe some code scan or some strong compiler :) > (Problem with my mail server so I can only see your mail on > website archive) Okay, I think we should go with the changes that I have in the webrev: http://cr.openjdk.java.net/~alanb/7030624/webrev/ Could I get a reviewer for this? As a reminder, the issue that Jing has brought up a few times is that this code is using size_t which is unsigned. The changes in the webrev change the return type to jint. -Alan. From xueming.shen at oracle.com Tue Nov 29 17:11:17 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 29 Nov 2011 09:11:17 -0800 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED4E6BB.1080908@gmx.de> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <4ED4E6BB.1080908@gmx.de> Message-ID: <4ED51235.1060300@oracle.com> That would be a separate RFE for that. As Mark suggested (as the feedback for the EFP) we now divide the zlib related work into small/separate rfes. To use the platform zlib is still on my list. -Sherman On 11/29/2011 06:05 AM, Ulf Zibis wrote: > Am 29.11.2011 11:23, schrieb Alan Bateman: >> When we talked about the zlib version here (I think back in February) >> we talked about having the option to use the system's zip library >> where appropriate. Have you given this any thought recently? > > +1 > > Ulf > From xueming.shen at oracle.com Tue Nov 29 17:29:47 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 29 Nov 2011 09:29:47 -0800 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED4B2A0.6050601@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> Message-ID: <4ED5168B.9080204@oracle.com> The test case has been updated accordingly to (1) reduced the data size to 500k (2) dialed down the loop iteration to 5 so it runs much faster now. The webrev has been updated. http://cr.openjdk.java.net/~sherman/7110149/webrev -Sherman On 11/29/2011 02:23 AM, Alan Bateman wrote: > On 28/11/2011 22:06, Xueming Shen wrote: >> Hi, >> >> Here is the webrev for upgrading the bundled zlib from 1.2.3 to 1.2.5 >> for JDK8 >> >> http://cr.openjdk.java.net/~sherman/7110149/webrev >> >> The changes to the original zlib source code (other than the >> copyright attachment) >> is at >> >> http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html >> >> >> For you reference, the 1.2.3 upgrade webrev can be found at >> >> http://cr.openjdk.java.net/~sherman/zlib123/webrev >> >> Thanks, >> Sherman > Thanks for doing this, the upgrade looks fine to me (assuming that > zlib1.2.3 is deleted). > > One concern about the test is that it would appear to be long running. > I grabbed it and tried it on my system with zlib1.2.3 and it took > about 25s, and just over 1m on a much older/slower machine. Maybe the > innermost loop could be dialed down, say to 5. It might be best to > drop the /timeout=1000 as the right way to increase the timeout on > really slow machines is to run with -timeoutFactor:N. > > Minor comment on the test is that new Random(new > Date().getTime()).nextBytes(dataIn) is a bit odd. Also might be nicer > if check didn't declare that its throws Throwable. > From Lance.Andersen at oracle.com Tue Nov 29 18:02:30 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 29 Nov 2011 13:02:30 -0500 Subject: 7116445: Miscellaneous warnings in the JDBC/RowSet classes Message-ID: Please review the following changes for JDBC area as part of the warnings clean up day. I will not be able to participate on Thursday so I wanted to try and get this done ahead of time. The changes can be found at http://cr.openjdk.java.net/~lancea/7116445/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Tue Nov 29 18:12:02 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 29 Nov 2011 13:12:02 -0500 Subject: A method with return type size_t returns negative value In-Reply-To: <4ED5062A.5020007@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> <4EC26A2B.9010106@oracle.com> <4ED34819.3040301@linux.vnet.ibm.com> <4ED5062A.5020007@oracle.com> Message-ID: <18E26DC4-F4A7-4DF7-9C28-BE22EB5BFA6A@oracle.com> looks ok to me... On Nov 29, 2011, at 11:19 AM, Alan Bateman wrote: > On 28/11/2011 08:36, Jing Lv wrote: >> Hello Alan, >> >> I am fine with the fix on the webrev, suppose it would be applied later? >> I don't remember (as it's been a long time) exactly I found the issue, maybe some code scan or some strong compiler :) >> (Problem with my mail server so I can only see your mail on website archive) > Okay, I think we should go with the changes that I have in the webrev: > > http://cr.openjdk.java.net/~alanb/7030624/webrev/ > > Could I get a reviewer for this? As a reminder, the issue that Jing has brought up a few times is that this code is using size_t which is unsigned. The changes in the webrev change the return type to jint. > > -Alan. > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Tue Nov 29 18:19:10 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 29 Nov 2011 13:19:10 -0500 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED503EB.6000708@oracle.com> References: <4ED503EB.6000708@oracle.com> Message-ID: <30A31568-EB39-407A-AB17-2A5A32BE3A53@oracle.com> Looks good to me Best Lance On Nov 29, 2011, at 11:10 AM, Alan Bateman wrote: > > I don't have time on Thursday to get involved in the warnings fest [1]. However I would like to contribute something and to that end the following webrev proposes changes to eliminate the warnings from several classes including java.rmi.**, the serialization classes, and several core classes: > > http://cr.openjdk.java.net/~alanb/7116404/webrev/ > > The changes are mostly trivial, and mostly to raw type usages. One tricky one ObjectInputStream.readEnum where I had to use a raw type (Maurizio and I chatted about this one and there doesn't seem to be a better workaround). There is one non-warnings change in java.rmi.server.LogStream where I replaced a usage of legacy Hashtable with a HashMap. > > -Alan. > > [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Tue Nov 29 19:02:00 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Nov 2011 19:02:00 +0000 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED5168B.9080204@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <4ED5168B.9080204@oracle.com> Message-ID: <4ED52C28.3080204@oracle.com> On 29/11/2011 17:29, Xueming Shen wrote: > The test case has been updated accordingly to > > (1) reduced the data size to 500k > (2) dialed down the loop iteration to 5 > > so it runs much faster now. > > The webrev has been updated. > > http://cr.openjdk.java.net/~sherman/7110149/webrev > Thanks, looks fine to me now. -Alan. From chris.hegarty at oracle.com Tue Nov 29 19:30:09 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Nov 2011 19:30:09 +0000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <30A31568-EB39-407A-AB17-2A5A32BE3A53@oracle.com> References: <4ED503EB.6000708@oracle.com> <30A31568-EB39-407A-AB17-2A5A32BE3A53@oracle.com> Message-ID: <4ED532C1.1040204@oracle.com> On 11/29/11 06:19 PM, Lance Andersen - Oracle wrote: > Looks good to me Me too. Just one minor opportunity for use of <> in ObjectInputStream < Class[] classObjs = new Class<*?*>[interfaces.length]; --- > Class[] classObjs = new Class<>[interfaces.length]; -Chris. > > Best > Lance > On Nov 29, 2011, at 11:10 AM, Alan Bateman wrote: > >> >> I don't have time on Thursday to get involved in the warnings fest [1]. However I would like to contribute something and to that end the following webrev proposes changes to eliminate the warnings from several classes including java.rmi.**, the serialization classes, and several core classes: >> >> http://cr.openjdk.java.net/~alanb/7116404/webrev/ >> >> The changes are mostly trivial, and mostly to raw type usages. One tricky one ObjectInputStream.readEnum where I had to use a raw type (Maurizio and I chatted about this one and there doesn't seem to be a better workaround). There is one non-warnings change in java.rmi.server.LogStream where I replaced a usage of legacy Hashtable with a HashMap. >> >> -Alan. >> >> [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From xueming.shen at oracle.com Tue Nov 29 19:38:26 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 29 Nov 2011 19:38:26 +0000 Subject: hg: jdk8/tl/jdk: 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Message-ID: <20111129193836.8F7FA4749D@hg.openjdk.java.net> Changeset: a47de985fec9 Author: sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/zip/FILES_c.gmk ! make/sun/splashscreen/FILES_c.gmk - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.5/ChangeLog + src/share/native/java/util/zip/zlib-1.2.5/README + src/share/native/java/util/zip/zlib-1.2.5/compress.c + src/share/native/java/util/zip/zlib-1.2.5/crc32.h + src/share/native/java/util/zip/zlib-1.2.5/deflate.c + src/share/native/java/util/zip/zlib-1.2.5/deflate.h + src/share/native/java/util/zip/zlib-1.2.5/gzclose.c + src/share/native/java/util/zip/zlib-1.2.5/gzguts.h + src/share/native/java/util/zip/zlib-1.2.5/gzlib.c + src/share/native/java/util/zip/zlib-1.2.5/gzread.c + src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c + src/share/native/java/util/zip/zlib-1.2.5/infback.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.h + src/share/native/java/util/zip/zlib-1.2.5/inffixed.h + src/share/native/java/util/zip/zlib-1.2.5/inflate.c + src/share/native/java/util/zip/zlib-1.2.5/inflate.h + src/share/native/java/util/zip/zlib-1.2.5/inftrees.c + src/share/native/java/util/zip/zlib-1.2.5/inftrees.h + src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.5/trees.c + src/share/native/java/util/zip/zlib-1.2.5/trees.h + src/share/native/java/util/zip/zlib-1.2.5/uncompr.c + src/share/native/java/util/zip/zlib-1.2.5/zadler32.c + src/share/native/java/util/zip/zlib-1.2.5/zconf.h + src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.5/zlib.h + src/share/native/java/util/zip/zlib-1.2.5/zutil.c + src/share/native/java/util/zip/zlib-1.2.5/zutil.h + test/java/util/zip/DeInflate.java From chris.hegarty at oracle.com Tue Nov 29 19:52:20 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 29 Nov 2011 19:52:20 +0000 Subject: A method with return type size_t returns negative value In-Reply-To: <18E26DC4-F4A7-4DF7-9C28-BE22EB5BFA6A@oracle.com> References: <4D89BB76.5060900@linux.vnet.ibm.com> <4D89CA29.7040302@oracle.com> <4D8AF3C4.7020005@linux.vnet.ibm.com> <4D8B3A6B.8040005@oracle.com> <4DB68125.7080003@linux.vnet.ibm.com> <4DB685AF.9070602@oracle.com> <4DC24218.6070009@linux.vnet.ibm.com> <4E12D5F2.4010409@linux.vnet.ibm.com> <4E27DFD5.4010904@linux.vnet.ibm.com> <4E282A6E.7010305@oracle.com> <4EBA4060.6030706@linux.vnet.ibm.com> <4EC21E55.3030106@linux.vnet.ibm.com> <4EC26A2B.9010106@oracle.com> <4ED34819.3040301@linux.vnet.ibm.com> <4ED5062A.5020007@oracle.com> <18E26DC4-F4A7-4DF7-9C28-BE22EB5BFA6A@oracle.com> Message-ID: <4ED537F4.10500@oracle.com> On 11/29/11 06:12 PM, Lance Andersen - Oracle wrote: > looks ok to me... +1 -Chris. > On Nov 29, 2011, at 11:19 AM, Alan Bateman wrote: > >> On 28/11/2011 08:36, Jing Lv wrote: >>> Hello Alan, >>> >>> I am fine with the fix on the webrev, suppose it would be applied later? >>> I don't remember (as it's been a long time) exactly I found the issue, maybe some code scan or some strong compiler :) >>> (Problem with my mail server so I can only see your mail on website archive) >> Okay, I think we should go with the changes that I have in the webrev: >> >> http://cr.openjdk.java.net/~alanb/7030624/webrev/ >> >> Could I get a reviewer for this? As a reminder, the issue that Jing has brought up a few times is that this code is using size_t which is unsigned. The changes in the webrev change the return type to jint. >> >> -Alan. >> >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From xueming.shen at oracle.com Tue Nov 29 21:04:41 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 29 Nov 2011 21:04:41 +0000 Subject: hg: jdk8/tl/jdk: 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Message-ID: <20111129210451.713F64749F@hg.openjdk.java.net> Changeset: 07e359b01d8a Author: sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) Reviewed-by: alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c + test/java/util/zip/TimeChecksum.java From lana.steuck at oracle.com Tue Nov 29 21:52:23 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 29 Nov 2011 21:52:23 +0000 Subject: hg: jdk8/tl/hotspot: 42 new changesets Message-ID: <20111129215350.DABB2474A0@hg.openjdk.java.net> Changeset: 869804b759e7 Author: jcoomes Date: 2011-11-04 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/869804b759e7 7108553: Bump the hs23 build number to 06 Reviewed-by: johnc Contributed-by: alejandro.murillo at oracle.com ! make/hotspot_version Changeset: 5bda8dae4e14 Author: never Date: 2011-10-23 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5bda8dae4e14 7103784: enable some flags by default Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 754110e02bd5 Author: never Date: 2011-10-23 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/754110e02bd5 7103380: assertion failure with -XX:+PrintNativeNMethods Reviewed-by: kvn, iveresov ! src/share/vm/asm/codeBuffer.cpp Changeset: 42783d1414b2 Author: never Date: 2011-10-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/42783d1414b2 Merge - make/templates/bsd-header Changeset: b20d64f83668 Author: twisti Date: 2011-10-24 07:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b20d64f83668 7090904: JSR 292: JRuby junit test crashes in PSScavengeRootsClosure::do_oop Reviewed-by: kvn, never, jrose ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp Changeset: 12d38ffcba2a Author: twisti Date: 2011-10-25 00:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12d38ffcba2a 7094138: JSR 292: JRuby junit test fails in CallSite.setTargetNormal: obj->is_oop() failed: sanity check Reviewed-by: iveresov, never ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2ec638646e86 Author: twisti Date: 2011-10-25 04:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ec638646e86 7101642: JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I Reviewed-by: kvn, iveresov ! src/share/vm/runtime/sharedRuntime.cpp Changeset: a6eef545f1a2 Author: never Date: 2011-10-25 08:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a6eef545f1a2 7103224: collision between __LEAF define in interfaceSupport.hpp and /usr/include/sys/cdefs.h with gcc Reviewed-by: never Contributed-by: Omair Majid ! src/share/vm/opto/addnode.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/interfaceSupport.hpp Changeset: e69a66a1457b Author: kvn Date: 2011-10-25 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e69a66a1457b 7059039: EA: don't change non-escaping state of NULL pointer Summary: NULL pointers do not escape but escape state propagation may change it leading to worser results. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: d8cb48376797 Author: kvn Date: 2011-10-26 06:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8cb48376797 7097546: Optimize use of CMOVE instructions Summary: Avoid CMove in a loop if possible. May generate CMove if it could be moved outside a loop. Reviewed-by: never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.hpp Changeset: cec1757a0134 Author: twisti Date: 2011-10-27 04:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cec1757a0134 7102657: JSR 292: C1 deoptimizes unlinked invokedynamic call sites infinitely Reviewed-by: never, bdelsart ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/opto/runtime.cpp Changeset: e0658a9b3f87 Author: kvn Date: 2011-10-27 09:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0658a9b3f87 7105364: JDK8 b10 hotspot: src/share/vm/ci/ciMethodHandle.cpp Error: Use "." or "->" Summary: Define ciMethodHandle::print_chain_impl() and ciMethodHandle::print_chain() bodies only in debug builds. Reviewed-by: never, twisti ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp Changeset: 34535d2cb362 Author: iveresov Date: 2011-10-27 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34535d2cb362 7104177: Tiered: -XX:+PrintCanonicalization doesn't work with -XX:+TieredCompilation Summary: Initialize printable_bci of instruction when passed to Canonicalizer Reviewed-by: kvn, never ! src/share/vm/c1/c1_Canonicalizer.hpp Changeset: f350490a45fd Author: kvn Date: 2011-10-27 18:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f350490a45fd 7105611: Set::print() is broken Summary: Reimplemented class VSetI_ to restore Set::print(). Reviewed-by: never ! src/share/vm/libadt/vectset.cpp ! src/share/vm/libadt/vectset.hpp Changeset: eba044a722a4 Author: never Date: 2011-10-28 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba044a722a4 7103261: crash with jittester on sparc Reviewed-by: iveresov, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp + test/compiler/7103261/Test7103261.java Changeset: e3b0dcc327b9 Author: twisti Date: 2011-10-31 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3b0dcc327b9 7104561: UseRDPCForConstantTableBase doesn't work after shorten branches changes Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/opto/machnode.cpp Changeset: 71699e9d8673 Author: kvn Date: 2011-10-31 15:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71699e9d8673 7106907: 64 bit VM fails test compiler/6865265/StackOverflowBug.java Summary: Use -Xss224k instead of -Xss128k. Reviewed-by: never ! test/compiler/6865265/StackOverflowBug.java Changeset: e342a5110bed Author: twisti Date: 2011-11-03 01:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e342a5110bed 7106774: JSR 292: nightly test inlineMHTarget fails with wrong result Reviewed-by: kvn ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 448691f285a5 Author: twisti Date: 2011-11-03 04:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/448691f285a5 7106944: assert(_pc == *pc_addr) failed may be too strong Reviewed-by: kvn, never ! src/cpu/x86/vm/frame_x86.cpp Changeset: 1feb272af3a7 Author: never Date: 2011-11-04 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1feb272af3a7 6636110: unaligned stackpointer leads to crash during deoptimization Reviewed-by: never, kvn Contributed-by: Andreas Schoesser ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: 59e515ee9354 Author: kvn Date: 2011-11-07 14:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59e515ee9354 7059047: EA: can't find initializing store with several CheckCastPP Summary: Split adjust_escape_state() method into two methods to find initializing stores. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 44ce519bc3d1 Author: never Date: 2011-11-08 10:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/44ce519bc3d1 7104960: JSR 292: +VerifyMethodHandles in product JVM can overflow buffer Reviewed-by: kvn, jrose, twisti ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: c9a03402fe56 Author: never Date: 2011-11-08 17:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9a03402fe56 7105305: assert check_method_context proper context Reviewed-by: jrose, kvn ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/constantPoolKlass.cpp Changeset: e3e363b2bf19 Author: never Date: 2011-11-08 20:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3e363b2bf19 7108242: jinfo -permstat shouldn't report interned strings as part of perm Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 83d0b5cd1438 Author: twisti Date: 2011-11-09 00:42 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83d0b5cd1438 7087727: JSR 292: C2 crash if ScavengeRootsInCode=2 when "static final" MethodHandle constants are in use Reviewed-by: jrose, kvn, never ! src/share/vm/opto/callGenerator.cpp Changeset: 7e0e43cf86d6 Author: kvn Date: 2011-11-09 06:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e0e43cf86d6 7109887: java/util/Arrays/CopyMethods.java fails with -XX:+DeoptimizeALot Summary: zero array when compiled code is deoptimized. Reviewed-by: never, twisti ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp Changeset: 670a74b863fc Author: kvn Date: 2011-11-09 07:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/670a74b863fc 7107042: assert(no_dead_loop) failed: dead loop detected Summary: Use dead nodes elimination code in PhaseIdealLoop before executing EA. Reviewed-by: never, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/globals.hpp Changeset: 78bef05801ca Author: twisti Date: 2011-11-10 04:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78bef05801ca Merge - src/share/vm/precompiled.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3c7d67df8d07 Author: dholmes Date: 2011-11-10 06:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c7d67df8d07 7108264: Fix for 7104173 is insufficient Summary: Disable PrintVMOptions by default for all builds Reviewed-by: dsamersoff, twisti ! src/share/vm/runtime/globals.hpp Changeset: f9a80a035a4a Author: coleenp Date: 2011-11-15 12:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9a80a035a4a Merge ! src/share/vm/runtime/globals.hpp Changeset: 5a5ed80bea5b Author: ysr Date: 2011-10-26 21:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a5ed80bea5b 7105163: CMS: some mentions of MinChunkSize should be IndexSetStart Summary: Fixed the instances that were missed in the changeset for 7099817. Reviewed-by: stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp Changeset: 59519b7d7b9d Author: tonyp Date: 2011-10-28 13:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59519b7d7b9d Merge Changeset: 6fd81579526f Author: brutisso Date: 2011-10-31 08:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6fd81579526f 7102044: G1: VM crashes with assert(old_end != new_end) failed: don't call this otherwise Summary: arrayOopDesc::max_array_length() should return a value that does not overflow a size_t if it is converted to bytes. Reviewed-by: kvn, dholmes ! make/jprt.properties ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! test/Makefile Changeset: ed80554efa25 Author: brutisso Date: 2011-11-02 08:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed80554efa25 7106751: G1: gc/gctests/nativeGC03 crashes VM with SIGSEGV Summary: _cset_rs_update_cl[] was indexed with values beyond what it is set up to handle. Reviewed-by: ysr, jmasa, johnc ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 8aae2050e83e Author: tonyp Date: 2011-11-07 22:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8aae2050e83e 7092309: G1: introduce old region set Summary: Keep track of all the old regions in the heap with a heap region set. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.cpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp Changeset: 53074c2c4600 Author: tonyp Date: 2011-11-08 00:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/53074c2c4600 7099849: G1: include heap region information in hs_err files Reviewed-by: johnc, brutisso, poonam ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/vmError.cpp Changeset: ab5107bee78c Author: brutisso Date: 2011-11-09 23:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab5107bee78c 7110190: GCCause::to_string missing case for _adaptive_size_policy Summary: Added case for _adaptive_size_policy Reviewed-by: johnc, ysr ! src/share/vm/gc_interface/gcCause.cpp Changeset: aa4c21b00f7f Author: brutisso Date: 2011-11-15 20:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa4c21b00f7f 7110152: assert(size_in_words <= (julong)max_jint) failed: no overflow Summary: Reduce what arrayOopDesc::max_array_length() returns to avoid int overflow Reviewed-by: kvn, dholmes, tonyp ! src/share/vm/oops/arrayOop.hpp Changeset: 2ceafe3ceb65 Author: poonam Date: 2011-11-16 16:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ceafe3ceb65 7110428: Crash during HeapDump operation Reviewed-by: ysr, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: b1754f3fbbd8 Author: tonyp Date: 2011-11-17 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b1754f3fbbd8 Merge Changeset: 6c2a55d4902f Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c2a55d4902f Merge Changeset: fde2a39ed7f3 Author: jcoomes Date: 2011-11-18 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fde2a39ed7f3 Added tag hs23-b06 for changeset 6c2a55d4902f ! .hgtags From lana.steuck at oracle.com Tue Nov 29 21:52:55 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 29 Nov 2011 21:52:55 +0000 Subject: hg: jdk8/tl/jdk: 9 new changesets Message-ID: <20111129215424.D1670474A1@hg.openjdk.java.net> Changeset: 2a147f854257 Author: twisti Date: 2011-11-02 02:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a147f854257 7085860: JSR 292: implement CallSite.setTargetNormal and setTargetVolatile as native methods Reviewed-by: jrose, never ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/CallSiteTest.java Changeset: 5c34ed65176e Author: twisti Date: 2011-11-09 00:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5c34ed65176e 7109063: JSR 292: fix for 7085860 is incomplete Reviewed-by: iveresov, alanb, jrose ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/ProblemList.txt ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: bdb2d63c176c Author: jcoomes Date: 2011-11-18 16:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdb2d63c176c Merge ! test/ProblemList.txt Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89952dc5be8e 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h Reviewed-by: prr, bae Contributed-by: littlee at linux.vnet.ibm.com ! src/share/native/sun/awt/medialib/mlib_types.h Changeset: 60331bbcf4ad Author: lana Date: 2011-11-18 16:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60331bbcf4ad Merge Changeset: 855675a4235b Author: lana Date: 2011-11-23 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/855675a4235b Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 3c248d0e2c48 Author: lana Date: 2011-11-28 15:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c248d0e2c48 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: c5313d712ab0 Author: lana Date: 2011-11-29 12:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a3edcdff37e1 Merge From stuart.marks at oracle.com Tue Nov 29 23:01:18 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Nov 2011 15:01:18 -0800 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED503EB.6000708@oracle.com> References: <4ED503EB.6000708@oracle.com> Message-ID: <4ED5643E.4080406@oracle.com> On 11/29/11 8:10 AM, Alan Bateman wrote: > I don't have time on Thursday to get involved in the warnings fest [1]. However > I would like to contribute something and to that end the following webrev > proposes changes to eliminate the warnings from several classes including > java.rmi.**, the serialization classes, and several core classes: > > http://cr.openjdk.java.net/~alanb/7116404/webrev/ Wow, you're getting a jump on us! Any idea how many warnings this cleared up? Looks like dozens. > The changes are mostly trivial, and mostly to raw type usages. One tricky one > ObjectInputStream.readEnum where I had to use a raw type (Maurizio and I > chatted about this one and there doesn't seem to be a better workaround). There > is one non-warnings change in java.rmi.server.LogStream where I replaced a > usage of legacy Hashtable with a HashMap. A couple comments on these: * The ObjectInputStream.readEnum case does indeed look tricky and so use of @SuppressWarnings is probably called for. Is it possible to use this annotation in a smaller scope than the entire method? In Effective Java, Josh Bloch recommends putting @SuppressWarnings on a declaration, even creating a new local variable if necessary. (He also recommends adding a comment.) Perhaps it's possible do to this here; while a local declaration within a try-block seems redundant, but it might enable narrowing the scope of @SuppressWarnings considerably. * Similar comment on java/rmi/MarshalledObject.get(). Looks to me like the only unchecked warning in there is at (old) line 159, which is a declaration, so @SuppressWarnings could be placed there instead of on the entire method. Thanks. s'marks > -Alan. > > [1] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html From stuart.marks at oracle.com Wed Nov 30 00:31:16 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 29 Nov 2011 16:31:16 -0800 Subject: 7116445: Miscellaneous warnings in the JDBC/RowSet classes In-Reply-To: References: Message-ID: <4ED57954.6040601@oracle.com> On 11/29/11 10:02 AM, Lance Andersen - Oracle wrote: > Please review the following changes for JDBC area as part of the warnings clean up day. I will not be able to participate on Thursday so I wanted to try and get this done ahead of time. > > The changes can be found at http://cr.openjdk.java.net/~lancea/7116445/webrev.00/ Hi Lance, thanks for jumping on the warnings bandwagon! I have a few comments and discussion points. * In CachedRowSetImpl.java, JdbcRowSetImpl.java and CachedRowSetReader.java, there are places where @SuppressWarnings("deprecation") is added to methods that are fairly long. If during further maintenance of these methods a use of another deprecated element is added, no warning will be issued. It might be nice to try to narrow the scope of the annotation, e.g. for CachedRowSetImpl you could do add this to the acceptChanges() method: @SuppressWarnings("deprecation") final boolean doCommit = this.COMMIT_ON_ACCEPT_CHANGES; and then use doCommit where COMMIT_ON_ACCEPT_CHANGES formerly was used. This would allow removal of the SuppressWarnings annotation from the entire method. (Changing this to CachedRowSet.COMMIT_ON_ACCEPT_CHANGES would remove additional warnings. Actually since this is a final boolean defined to be true in an interface, it can't be changed, so maybe use of this value can be removed entirely. (But perhaps this is too much JDBC history for you to get into right now.)) In JdbcRowSetImpl and CachedRowSetReader dealing with the use of deprecated PreparedStatement.setUnicodeStream is trickier. There's no obvious way to add a local declaration on which one can place the annotation. I suppose you could refactor the call into a small method of its own, but this seems like overkill. Up to you as to whether you want to do anything on these. * In CachedRowSetWriter.java, cols is changed from Vector to Vector. This is fine but there's now a redundant cast (Integer)cols.get(i) at line 752 that might generate another warning. * Also in CachedRowSetWriter.java, line 308 can use diamond: status = new ArrayList<>(sz); Up to you whether you want to use diamond here since the creation is separate from the declaration. Further note that this sets up a potentially similar redundant cast for the result of status.get(), however, the line where it's used does this: if (! ((status.get(j)).equals(Integer.valueOf(SyncResolver.NO_ROW_CONFLICT)))) Although this doesn't generate a warning I think you can simplify this to if (status.get(j) != SyncResolver.NO_ROW_CONFLICT) * similar redundant cast at line 535, (String)stack.pop(), since stack is now Stack. Oh, again you might want to use diamond where stack is initialized. * WebRowSetXmlWriter.java, XmlReaderContentHandler.java, SQLInputImpl.java, and SyncFactory.java similar removals of redundant casts can be performed for types that have been converted to generics. This usually occurs near a get() call, e.g. in XmlReaderContentHandler, since propMap is now HashMap, usages can be simplified from tag = ((Integer)propMap.get(name)).intValue(); to tag = propMap.get(name); You might also consider using diamond where new generic instances are created, though it's a matter of style whether to use diamond in an assignment statement (as opposed to in a declaration's initializer). Thanks, s'marks From david.holmes at oracle.com Wed Nov 30 05:33:33 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 15:33:33 +1000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED503EB.6000708@oracle.com> References: <4ED503EB.6000708@oracle.com> Message-ID: <4ED5C02D.6080303@oracle.com> cc'ing to jdk8-dev so that people know these classes have already been tackled. David On 30/11/2011 2:10 AM, Alan Bateman wrote: > > I don't have time on Thursday to get involved in the warnings fest [1]. > However I would like to contribute something and to that end the > following webrev proposes changes to eliminate the warnings from several > classes including java.rmi.**, the serialization classes, and several > core classes: > > http://cr.openjdk.java.net/~alanb/7116404/webrev/ > > The changes are mostly trivial, and mostly to raw type usages. One > tricky one ObjectInputStream.readEnum where I had to use a raw type > (Maurizio and I chatted about this one and there doesn't seem to be a > better workaround). There is one non-warnings change in > java.rmi.server.LogStream where I replaced a usage of legacy Hashtable > with a HashMap. > > -Alan. > > [1] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-November/000302.html From david.holmes at oracle.com Wed Nov 30 05:50:23 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 15:50:23 +1000 Subject: 7116445: Miscellaneous warnings in the JDBC/RowSet classes In-Reply-To: References: Message-ID: <4ED5C41F.9010504@oracle.com> cc'ing to jdk8-dev so that people know these classes have already been tackled. David On 30/11/2011 4:02 AM, Lance Andersen - Oracle wrote: > Please review the following changes for JDBC area as part of the warnings clean up day. I will not be able to participate on Thursday so I wanted to try and get this done ahead of time. > > The changes can be found at http://cr.openjdk.java.net/~lancea/7116445/webrev.00/ > > Best > Lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Alan.Bateman at oracle.com Wed Nov 30 09:43:55 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Nov 2011 09:43:55 +0000 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <20111130013116.GD32372@rivendell.middle-earth.co.uk> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <20111130013116.GD32372@rivendell.middle-earth.co.uk> Message-ID: <4ED5FADB.6090704@oracle.com> On 30/11/2011 01:31, Dr Andrew John Hughes wrote: > On 10:23 Tue 29 Nov , Alan Bateman wrote: > > snip... > >> When we talked about the zlib version here (I think back in February) we >> talked about having the option to use the system's zip library where >> appropriate. Have you given this any thought recently? >> >> -Alan. > We have changes for this (and other libraries) in IcedTea that we'd like > to upstream. I'll look at posting a webrev soon. That would be great. If I remember correctly then the IcedTea patches remove the zlib code completely but we can't do that of course because of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best. -Alan. From david.holmes at oracle.com Wed Nov 30 09:50:31 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 19:50:31 +1000 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED5FADB.6090704@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <20111130013116.GD32372@rivendell.middle-earth.co.uk> <4ED5FADB.6090704@oracle.com> Message-ID: <4ED5FC67.4080602@oracle.com> On 30/11/2011 7:43 PM, Alan Bateman wrote: > On 30/11/2011 01:31, Dr Andrew John Hughes wrote: >> On 10:23 Tue 29 Nov , Alan Bateman wrote: >> >> snip... >> >>> When we talked about the zlib version here (I think back in February) we >>> talked about having the option to use the system's zip library where >>> appropriate. Have you given this any thought recently? >>> >>> -Alan. >> We have changes for this (and other libraries) in IcedTea that we'd like >> to upstream. I'll look at posting a webrev soon. > That would be great. If I remember correctly then the IcedTea patches > remove the zlib code completely but we can't do that of course because > of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best. FYI the macosx port is also adding a SYSTEM_ZLIB option: http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ David > -Alan. > From Alan.Bateman at oracle.com Wed Nov 30 10:00:30 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Nov 2011 10:00:30 +0000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED5643E.4080406@oracle.com> References: <4ED503EB.6000708@oracle.com> <4ED5643E.4080406@oracle.com> Message-ID: <4ED5FEBE.8080008@oracle.com> On 29/11/2011 23:01, Stuart Marks wrote: > On 11/29/11 8:10 AM, Alan Bateman wrote: >> : >> >> http://cr.openjdk.java.net/~alanb/7116404/webrev/ > > Wow, you're getting a jump on us! Any idea how many warnings this > cleared up? Looks like dozens. 110, so not too many. There is still plenty of low hanging cider for everyone. > : > A couple comments on these: > > * The ObjectInputStream.readEnum case does indeed look tricky and so > use of @SuppressWarnings is probably called for. Is it possible to use > this annotation in a smaller scope than the entire method? That's a good point, I've changed ObjectInputStream.readEnum and MarshalledObject.get so that that the @SuppressWarnings is at the declaration so it reduces its scope. The webrev is updated. I'll try to push this today before tomorrow's storm. -Alan. From chris.hegarty at oracle.com Wed Nov 30 10:09:09 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Nov 2011 10:09:09 +0000 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED5FC67.4080602@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <20111130013116.GD32372@rivendell.middle-earth.co.uk> <4ED5FADB.6090704@oracle.com> <4ED5FC67.4080602@oracle.com> Message-ID: <4ED600C5.1030402@oracle.com> On 30/11/2011 09:50, David Holmes wrote: > On 30/11/2011 7:43 PM, Alan Bateman wrote: >> On 30/11/2011 01:31, Dr Andrew John Hughes wrote: >>> On 10:23 Tue 29 Nov , Alan Bateman wrote: >>> >>> snip... >>> >>>> When we talked about the zlib version here (I think back in >>>> February) we >>>> talked about having the option to use the system's zip library where >>>> appropriate. Have you given this any thought recently? >>>> >>>> -Alan. >>> We have changes for this (and other libraries) in IcedTea that we'd like >>> to upstream. I'll look at posting a webrev soon. >> That would be great. If I remember correctly then the IcedTea patches >> remove the zlib code completely but we can't do that of course because >> of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best. > > FYI the macosx port is also adding a SYSTEM_ZLIB option: > > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ So this is a compile time decision, if you are targeting a platform that is known to have a system zip library you simply link against that. Nice! I've also been looking at the possibility ( for a different reason ) of using supporting the system version of a library (if one is available) instead of the bundled version. This is to allow support of more recent versions of the system library to be used, rather than what may be an older bundled version, and targets platforms where a system library may or may not be available. Is this something that may be relevant here, or are we always guaranteed that the system will have a zip library available on our targeted OS-ARCH binaries? -Chris. > > David > >> -Alan. >> From forax at univ-mlv.fr Wed Nov 30 15:06:15 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 Nov 2011 16:06:15 +0100 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED5FEBE.8080008@oracle.com> References: <4ED503EB.6000708@oracle.com> <4ED5643E.4080406@oracle.com> <4ED5FEBE.8080008@oracle.com> Message-ID: <4ED64667.5080202@univ-mlv.fr> On 11/30/2011 11:00 AM, Alan Bateman wrote: > On 29/11/2011 23:01, Stuart Marks wrote: >> On 11/29/11 8:10 AM, Alan Bateman wrote: >>> : >>> >>> http://cr.openjdk.java.net/~alanb/7116404/webrev/ >> >> Wow, you're getting a jump on us! Any idea how many warnings this >> cleared up? Looks like dozens. > 110, so not too many. There is still plenty of low hanging cider for > everyone. > > >> : >> A couple comments on these: >> >> * The ObjectInputStream.readEnum case does indeed look tricky and so >> use of @SuppressWarnings is probably called for. Is it possible to >> use this annotation in a smaller scope than the entire method? > That's a good point, I've changed ObjectInputStream.readEnum and > MarshalledObject.get so that that the @SuppressWarnings is at the > declaration so it reduces its scope. The webrev is updated. I'll try > to push this today before tomorrow's storm. Note that you can use clazz.asSubclass(Enum.class) instead of casting to the raw type Class, you will still have a warning but you will be not the one that have introduced a raw type :) > > -Alan. > R?mi From alan.bateman at oracle.com Wed Nov 30 15:26:40 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 30 Nov 2011 15:26:40 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20111130152715.55301474B0@hg.openjdk.java.net> Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4749df4f04f1 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited Reviewed-by: lancea, chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: 7795c41ed54c Author: alanb Date: 2011-11-30 12:42 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7795c41ed54c 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Reviewed-by: lancea, chegar, smarks ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java From Alan.Bateman at oracle.com Wed Nov 30 15:50:59 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Nov 2011 15:50:59 +0000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED64667.5080202@univ-mlv.fr> References: <4ED503EB.6000708@oracle.com> <4ED5643E.4080406@oracle.com> <4ED5FEBE.8080008@oracle.com> <4ED64667.5080202@univ-mlv.fr> Message-ID: <4ED650E3.6060708@oracle.com> On 30/11/2011 15:06, R?mi Forax wrote: > > Note that you can use clazz.asSubclass(Enum.class) instead of casting > to the raw type Class, > you will still have a warning but you will be not the one that have > introduced a raw type :) Your mail arrived just a few minutes after I did the hg push. The only thing about using asSubClass(Enum.class) is that it might not be as obvious to the reader. As you say it would result in a warning too but thanks for going through these changes too. -Alan From chris.hegarty at oracle.com Wed Nov 30 16:24:06 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Nov 2011 16:24:06 +0000 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED5FEBE.8080008@oracle.com> References: <4ED503EB.6000708@oracle.com> <4ED5643E.4080406@oracle.com> <4ED5FEBE.8080008@oracle.com> Message-ID: <4ED658A6.4020406@oracle.com> On 30/11/2011 10:00, Alan Bateman wrote: > On 29/11/2011 23:01, Stuart Marks wrote: >> On 11/29/11 8:10 AM, Alan Bateman wrote: >>> : >>> >>> http://cr.openjdk.java.net/~alanb/7116404/webrev/ >> >> Wow, you're getting a jump on us! Any idea how many warnings this >> cleared up? Looks like dozens. > 110, so not too many. There is still plenty of low hanging cider for > everyone. > > >> : >> A couple comments on these: >> >> * The ObjectInputStream.readEnum case does indeed look tricky and so >> use of @SuppressWarnings is probably called for. Is it possible to use >> this annotation in a smaller scope than the entire method? > That's a good point, I've changed ObjectInputStream.readEnum and > MarshalledObject.get so that that the @SuppressWarnings is at the > declaration so it reduces its scope. The webrev is updated. I'll try to > push this today before tomorrow's storm. Looks fine to me. -Chris. > > -Alan. > From chris.hegarty at oracle.com Wed Nov 30 16:33:47 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Nov 2011 16:33:47 +0000 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) Message-ID: <4ED65AEB.60200@oracle.com> I started to look at the reason why we suppressed unchecked warning for sun.misc.Service in a few places, and this lead me into some other sun.misc classes. Here's a change that fixes a few warnings in this area. http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ -Chris. From forax at univ-mlv.fr Wed Nov 30 16:38:59 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 Nov 2011 17:38:59 +0100 Subject: 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) In-Reply-To: <4ED650E3.6060708@oracle.com> References: <4ED503EB.6000708@oracle.com> <4ED5643E.4080406@oracle.com> <4ED5FEBE.8080008@oracle.com> <4ED64667.5080202@univ-mlv.fr> <4ED650E3.6060708@oracle.com> Message-ID: <4ED65C23.7060604@univ-mlv.fr> On 11/30/2011 04:50 PM, Alan Bateman wrote: > On 30/11/2011 15:06, R?mi Forax wrote: >> >> Note that you can use clazz.asSubclass(Enum.class) instead of casting >> to the raw type Class, >> you will still have a warning but you will be not the one that have >> introduced a raw type :) > Your mail arrived just a few minutes after I did the hg push. The only > thing about using asSubClass(Enum.class) is that it might not be as > obvious to the reader. As you say it would result in a warning too but > thanks for going through these changes too. > > -Alan Not a big deal. If we were before the release of tiger, we can: - fix the Foo.class syntax to return Class> - fix object.getClass() to also returns a wildcard - fix Enum.valueOf to take an Class instead of a Class - fix the compiler/spec because Enum should be an > Enum so too many changes and most of them are incompatible with the current state of the language. The only way I see to solve the problem now is to add a method in java.lang.Class named getEnumConstant() that takes a String an return an Enum. R?mi From Alan.Bateman at oracle.com Wed Nov 30 16:56:35 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Nov 2011 16:56:35 +0000 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <4ED65AEB.60200@oracle.com> References: <4ED65AEB.60200@oracle.com> Message-ID: <4ED66043.3030108@oracle.com> On 30/11/2011 16:33, Chris Hegarty wrote: > I started to look at the reason why we suppressed unchecked warning > for sun.misc.Service in a few places, and this lead me into some other > sun.misc classes. Here's a change that fixes a few warnings in this area. > > http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ > > -Chris. It's nice to see existing @SuppressWarnings going away. What would you think of just biting the bullet and getting InetAddress and the http server switched over to using ServiceLoader? In ExtensionDependency.installExtension then I assume you could assign to a temporary variable with the @SuppressWarnings("unchecked") at the declaration and avoid the uncheckedClone. -Alan. From joe.darcy at oracle.com Wed Nov 30 17:04:47 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Nov 2011 09:04:47 -0800 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <4ED66043.3030108@oracle.com> References: <4ED65AEB.60200@oracle.com> <4ED66043.3030108@oracle.com> Message-ID: <4ED6622F.2080901@oracle.com> On 11/30/2011 8:56 AM, Alan Bateman wrote: > On 30/11/2011 16:33, Chris Hegarty wrote: >> I started to look at the reason why we suppressed unchecked warning >> for sun.misc.Service in a few places, and this lead me into some >> other sun.misc classes. Here's a change that fixes a few warnings in >> this area. >> >> http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ >> >> -Chris. > It's nice to see existing @SuppressWarnings going away. > > What would you think of just biting the bullet and getting InetAddress > and the http server switched over to using ServiceLoader? I was going to suggest the same. > > In ExtensionDependency.installExtension then I assume you could assign > to a temporary variable with the @SuppressWarnings("unchecked") at the > declaration and avoid the uncheckedClone. > > A few other comments: In this code, public JarIndex() { - indexMap = new HashMap(); - jarMap = new HashMap(); + indexMap = new HashMap>(); + jarMap = new HashMap>(); } I believe diamond could be used to initalize indexMap and jarMap. (Not using diamond here may be a style choice.) Otherwise, looks good. -Joe From forax at univ-mlv.fr Wed Nov 30 17:11:45 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 30 Nov 2011 18:11:45 +0100 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <4ED66043.3030108@oracle.com> References: <4ED65AEB.60200@oracle.com> <4ED66043.3030108@oracle.com> Message-ID: <4ED663D1.6050106@univ-mlv.fr> On 11/30/2011 05:56 PM, Alan Bateman wrote: > On 30/11/2011 16:33, Chris Hegarty wrote: >> I started to look at the reason why we suppressed unchecked warning >> for sun.misc.Service in a few places, and this lead me into some >> other sun.misc classes. Here's a change that fixes a few warnings in >> this area. >> >> http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ >> >> -Chris. > It's nice to see existing @SuppressWarnings going away. > > What would you think of just biting the bullet and getting InetAddress > and the http server switched over to using ServiceLoader? > > In ExtensionDependency.installExtension then I assume you could assign > to a temporary variable with the @SuppressWarnings("unchecked") at the > declaration and avoid the uncheckedClone. > > -Alan. Hi Chris, In your patch, JarIndex constructor should use diamond syntax. R?mi From xueming.shen at oracle.com Wed Nov 30 17:30:36 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 30 Nov 2011 09:30:36 -0800 Subject: zlib 1.2.3 -> 1.2.5 In-Reply-To: <4ED600C5.1030402@oracle.com> References: <4ED405FA.3010204@oracle.com> <4ED4B2A0.6050601@oracle.com> <20111130013116.GD32372@rivendell.middle-earth.co.uk> <4ED5FADB.6090704@oracle.com> <4ED5FC67.4080602@oracle.com> <4ED600C5.1030402@oracle.com> Message-ID: <4ED6683C.10609@oracle.com> There is a > 2/4G support issue we will need to address when using the platform bundled zlib. The total_in/total_out variables of z_stream_s is "long", which is not "big" enough (32 bit) for ZIP64 support on a 32-bit platform. The zlib code bundled with JDK has been updated to use "long long", as the (4)(5)(6) in ChangeLog_java at http://cr.openjdk.java.net/~sherman/7110149/webrev/src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java.html The Deflater/Inflater.getgetByteRead/Written() now use z_stream_s.total_in/out "directly", so it will not be able to report the correct totalRead/Written value if the value > 2G/4G, though it might be rare to deflate/inflate a >2/4G chunk of data. A possible solution is to accumulate the "totalRead/Written" at java level, so as long as you don't pass in data > 2g/4g in one invocation, it should be fine. -Sherman On 11/30/2011 02:09 AM, Chris Hegarty wrote: > On 30/11/2011 09:50, David Holmes wrote: >> On 30/11/2011 7:43 PM, Alan Bateman wrote: >>> On 30/11/2011 01:31, Dr Andrew John Hughes wrote: >>>> On 10:23 Tue 29 Nov , Alan Bateman wrote: >>>> >>>> snip... >>>> >>>>> When we talked about the zlib version here (I think back in >>>>> February) we >>>>> talked about having the option to use the system's zip library where >>>>> appropriate. Have you given this any thought recently? >>>>> >>>>> -Alan. >>>> We have changes for this (and other libraries) in IcedTea that we'd >>>> like >>>> to upstream. I'll look at posting a webrev soon. >>> That would be great. If I remember correctly then the IcedTea patches >>> remove the zlib code completely but we can't do that of course because >>> of Windows. So I think a USE_SYSTEM_ZLIB as you suggest would be best. >> >> FYI the macosx port is also adding a SYSTEM_ZLIB option: >> >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > So this is a compile time decision, if you are targeting a platform > that is known to have a system zip library you simply link against > that. Nice! > > I've also been looking at the possibility ( for a different reason ) > of using supporting the system version of a library (if one is > available) instead of the bundled version. This is to allow support of > more recent versions of the system library to be used, rather than > what may be an older bundled version, and targets platforms where a > system library may or may not be available. > > Is this something that may be relevant here, or are we always > guaranteed that the system will have a zip library available on our > targeted OS-ARCH binaries? > > -Chris. > >> >> David >> >>> -Alan. >>> From tom.hawtin at oracle.com Wed Nov 30 17:31:35 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Wed, 30 Nov 2011 17:31:35 +0000 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <4ED6622F.2080901@oracle.com> References: <4ED65AEB.60200@oracle.com> <4ED66043.3030108@oracle.com> <4ED6622F.2080901@oracle.com> Message-ID: <4ED66877.8000509@oracle.com> On 30/11/2011 17:04, Joe Darcy wrote: > public JarIndex() { > - indexMap = new HashMap(); > - jarMap = new HashMap(); > + indexMap = new HashMap>(); > + jarMap = new HashMap>(); jarMap = new HashMap>(); or similar might be better. Looks a bit O(n^2). But that's a different sort of style. Tom From brandon.passanisi at oracle.com Wed Nov 30 18:09:43 2011 From: brandon.passanisi at oracle.com (Brandon Passanisi) Date: Wed, 30 Nov 2011 10:09:43 -0800 Subject: Code Review Request for Bug #4802647 In-Reply-To: <4ECAE589.7050401@oracle.com> References: <4EC7049B.2090605@oracle.com> <4EC9B517.2010200@oracle.com> <4ECA986C.8090500@oracle.com> <4ECAE589.7050401@oracle.com> Message-ID: <4ED67166.7070303@oracle.com> On 11/21/2011 3:58 PM, David Holmes wrote: > On 22/11/2011 4:29 AM, Brandon Passanisi wrote: >> Thank you for the review David. I'll make the changes to the test >> program as you have suggested and I will also update the bug report with >> the comments you have given. I'll then send out an updated webrev. Just >> to double-check, when you mention "But I don't see a way around it" in >> regards to the fix to AbstractCollection.java... it sounds like you >> agree to keep the change as-is. Is this correct? > > Your fix is correct, but I'm not sure that fixing this bug is the best > thing to do here. You could easily argue to amend the spec instead. > That said, Josh Bloch already indicated (back in 2003) in the CR that > this should be fixed. > > I'd like to hear the opinions of other Collections experts. > > David Are there any opinions on this from other Collections experts? > > >> On 11/20/2011 6:19 PM, David Holmes wrote: >>> Hi Brandon, >>> >>> On 19/11/2011 11:21 AM, Brandon Passanisi wrote: >>>> Hello core-libs-dev at openjdk.java.net. Please review the following >>>> patch >>>> to fix Bug 4802647 (coll) NullPointerException not thrown by >>>> AbstractCollection.retainAll/removeAll: The fix is quite small and I >>>> have included a test program, all of which can be found within the >>>> following webrev: >>>> >>>> http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ >>> >>> The bug report is a little misleading. The bug only exists when the >>> current collection is empty - in which case we skip most of the method >>> body. Otherwise we will generate the NPE when we call >>> c.contains(iter.next()). The CR should be updated to note this. >>> >>> So while your fix is correct, I hate to see good code penalized >>> (explicit null check) to allow bad code to throw exceptions as >>> required. But I don't see a way around it. >>> >>> With regard to the test program - it can be simplified somewhat as >>> unexpected exceptions can just be allowed to propagate and failures to >>> throw can be detected inline: >>> >>> public static void main(String[] args) { >>> >>> // Ensure removeAll(null) throws NullPointerException >>> try { >>> (new NewAbstractCollection<>()).removeAll(null); >>> fail("NullPointerException not thrown for removeAll(null)."); >>> } catch (NullPointerException expected) { >>> } >>> >>> // Ensure retainAll(null) throws NullPointerException >>> try { >>> (new NewAbstractCollection<>()).retainAll(null); >>> fail("NullPointerException not thrown for retainAll(null)."); >>> } catch (NullPointerException expected) { >>> } >>> } >>> >>> Cheers, >>> David >>> >>>> Thanks. >> -- Oracle Brandon Passanisi | Principle Member of Technical Staff Oracle Java Standards Conformance Green Oracle Oracle is committed to developing practices and products that help protect the environment From Lance.Andersen at oracle.com Wed Nov 30 18:43:24 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 30 Nov 2011 13:43:24 -0500 Subject: 7116445: Miscellaneous warnings in the JDBC/RowSet classes In-Reply-To: <4ED57954.6040601@oracle.com> References: <4ED57954.6040601@oracle.com> Message-ID: <5C0D27F9-3942-452A-9380-B7C4CB475F07@oracle.com> Hi Stuart, Thanks for the feedback. On Nov 29, 2011, at 7:31 PM, Stuart Marks wrote: > On 11/29/11 10:02 AM, Lance Andersen - Oracle wrote: >> Please review the following changes for JDBC area as part of the warnings clean up day. I will not be able to participate on Thursday so I wanted to try and get this done ahead of time. >> >> The changes can be found at http://cr.openjdk.java.net/~lancea/7116445/webrev.00/ > > Hi Lance, thanks for jumping on the warnings bandwagon! > > I have a few comments and discussion points. > > * In CachedRowSetImpl.java, JdbcRowSetImpl.java and CachedRowSetReader.java, there are places where @SuppressWarnings("deprecation") is added to methods that are fairly long. If during further maintenance of these methods a use of another deprecated element is added, no warning will be issued. It might be nice to try to narrow the scope of the annotation, e.g. for CachedRowSetImpl you could do add this to the acceptChanges() method: > > @SuppressWarnings("deprecation") > final boolean doCommit = this.COMMIT_ON_ACCEPT_CHANGES; > > and then use doCommit where COMMIT_ON_ACCEPT_CHANGES formerly was used. This would allow removal of the SuppressWarnings annotation from the entire method. > > (Changing this to CachedRowSet.COMMIT_ON_ACCEPT_CHANGES would remove additional warnings. Actually since this is a final boolean defined to be true in an interface, it can't be changed, so maybe use of this value can be removed entirely. (But perhaps this is too much JDBC history for you to get into right now.)) I went back and removed this though I was somewhat hesitant due to the history though I am not sure why the original authors of the spec did this anyways (which is why I deprecated it). Ran the RowSet TCK to validate there were no hiccups (though there should not have been) > > In JdbcRowSetImpl and CachedRowSetReader dealing with the use of deprecated PreparedStatement.setUnicodeStream is trickier. There's no obvious way to add a local declaration on which one can place the annotation. I suppose you could refactor the call into a small method of its own, but this seems like overkill. Up to you as to whether you want to do anything on these. For now, I would rather leave it as is and will go back and revisit this later after I give it some more thought. > > * In CachedRowSetWriter.java, cols is changed from Vector to Vector. This is fine but there's now a redundant cast (Integer)cols.get(i) at line 752 that might generate another warning. I removed it now. btw, there was no warning generated with cast there which is why I did not make the change initially. > > * Also in CachedRowSetWriter.java, line 308 can use diamond: > > status = new ArrayList<>(sz); changed this > Up to you whether you want to use diamond here since the creation is separate from the declaration. > > Further note that this sets up a potentially similar redundant cast for the result of status.get(), however, the line where it's used does this: > > if (! ((status.get(j)).equals(Integer.valueOf(SyncResolver.NO_ROW_CONFLICT)))) > > Although this doesn't generate a warning I think you can simplify this to > > if (status.get(j) != SyncResolver.NO_ROW_CONFLICT) made the suggested changes > > * similar redundant cast at line 535, (String)stack.pop(), since stack is now Stack. Oh, again you might want to use diamond where stack is initialized. made the suggested changes > > * WebRowSetXmlWriter.java, XmlReaderContentHandler.java, SQLInputImpl.java, and SyncFactory.java similar removals of redundant casts can be performed for types that have been converted to generics. I did not see the changes you were suggesting in SyncFactory but maybe I have not had enough coffee :-), was there something specific you saw as I did not see an obvious change to get rid of the couple of casts to the type that was converted to use generics > This usually occurs near a get() call, e.g. in XmlReaderContentHandler, since propMap is now HashMap, usages can be simplified from > > tag = ((Integer)propMap.get(name)).intValue(); > > to > > tag = propMap.get(name); > > You might also consider using diamond where new generic instances are created, though it's a matter of style whether to use diamond in an assignment statement (as opposed to in a declaration's initializer). Do we have a preference going forward? I used diamond as you suggested. The updated webrev is at: http://cr.openjdk.java.net/~lancea/7116445/webrev.01/ Thank you for your review comments Best Lance > > Thanks, > > s'marks Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Wed Nov 30 19:02:54 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 30 Nov 2011 14:02:54 -0500 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <4ED65AEB.60200@oracle.com> References: <4ED65AEB.60200@oracle.com> Message-ID: <8B0B8C27-FBF0-4461-9FEC-E41C94682D04@oracle.com> Hi Chris, Do you want to use diamond reference on lines 81, 82 of jarindex.java? In Signal.java, line 203, i do not think you need new Integer() any longer? Other than that it looks good Best Lance On Nov 30, 2011, at 11:33 AM, Chris Hegarty wrote: > I started to look at the reason why we suppressed unchecked warning for sun.misc.Service in a few places, and this lead me into some other sun.misc classes. Here's a change that fixes a few warnings in this area. > > http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ > > -Chris. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Wed Nov 30 20:58:21 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 30 Nov 2011 12:58:21 -0800 Subject: 7116445: Miscellaneous warnings in the JDBC/RowSet classes In-Reply-To: <5C0D27F9-3942-452A-9380-B7C4CB475F07@oracle.com> References: <4ED57954.6040601@oracle.com> <5C0D27F9-3942-452A-9380-B7C4CB475F07@oracle.com> Message-ID: <4ED698ED.3050304@oracle.com> On 11/30/11 10:43 AM, Lance Andersen - Oracle wrote: > Hi Stuart, > > Thanks for the feedback. Great, thanks for the updates. Further comments below. >> * In CachedRowSetWriter.java, cols is changed from Vector to Vector. >> This is fine but there's now a redundant cast (Integer)cols.get(i) at line >> 752 that might generate another warning. > > I removed it now. btw, there was no warning generated with cast there which is > why I did not make the change initially. I'm not sure what the default compiler flags are for this portion of the build. I had done a full build of the jdk repo with your patch applied, using the following command, make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL= OTHER_JAVACFLAGS="-Xmaxwarns 10000" and I did see that some redundant cast warnings were introduced. >> * WebRowSetXmlWriter.java, XmlReaderContentHandler.java, SQLInputImpl.java, >> and SyncFactory.java similar removals of redundant casts can be performed for >> types that have been converted to generics. > > I did not see the changes you were suggesting in SyncFactory but maybe I have > not had enough coffee :-), was there something specific you saw as I did not > see an obvious change to get rid of the couple of casts to the type that was > converted to use generics Oh yes, the SyncFactory one is different. Usually generifying a type will introduce redundant casts near calls to things like get(). The "implementations" field was generified, and I saw this: ProviderImpl impl = (ProviderImpl) implementations.get(providerID); which looked like a redundant cast. But the declared type is now Hashtable which means the cast isn't redundant, but it does raise a different set of questions. The "impl" local is only tested for being null so maybe its type should be SyncProvider instead. Oddly it doesn't appear to be used if it's non-null. Hm, this code has other issues as well... (A null return from Class.forName is handled, which AFAIK cannot occur; c.newInstance() is cast to SyncProvider but ClassCastException isn't handled.) Despite this I don't actually see any compiler warnings from this code. Since this is warnings cleanup day maybe we're done. :-) Perhaps further cleanups in this area can be deferred. >> You might also consider using diamond where new generic instances are >> created, though it's a matter of style whether to use diamond in an >> assignment statement (as opposed to in a declaration's initializer). > > Do we have a preference going forward? I used diamond as you suggested. My recommendation is to use diamond in field and local initializers and in simple assignment statements. I avoid diamond in parameters to method calls and within ternary (?:) expressions. Some people don't want to use diamond in assignment statements, since the redundancy isn't as obvious, and they think that having the type arguments in the constructor is helpful there. But I don't see it. > The updated webrev is at: http://cr.openjdk.java.net/~lancea/7116445/webrev.01/ Oh... one more thing. Sorry I missed this in my previous review. In SQLOutputImpl the constructor parameters got changed from Vector to Vector and from Map to Map>. This looks like a public constructor to a public API class. (At least, I see this in the javadoc.) This change might actually be correct (though perhaps not strictly compatible) but I don't think we want to be making such changes as part of warnings cleanup, even if it does end up removing warnings. s'marks From stuart.marks at oracle.com Wed Nov 30 21:12:23 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 30 Nov 2011 21:12:23 +0000 Subject: hg: jdk8/tl/jdk: 7116322: enhance javac make rule with a little bit of instrumentation Message-ID: <20111130211232.E8AE1474C4@hg.openjdk.java.net> Changeset: 43a630f11af6 Author: smarks Date: 2011-11-30 13:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43a630f11af6 7116322: enhance javac make rule with a little bit of instrumentation Reviewed-by: dholmes, ohair ! make/common/Rules.gmk From jason_mehrens at hotmail.com Wed Nov 30 22:04:22 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 30 Nov 2011 16:04:22 -0600 Subject: Code Review Request for Bug #4802647 In-Reply-To: <4ED67166.7070303@oracle.com> References: <4EC7049B.2090605@oracle.com> <4EC9B517.2010200@oracle.com>,<4ECA986C.8090500@oracle.com> <4ECAE589.7050401@oracle.com>,<4ED67166.7070303@oracle.com> Message-ID: Brandon, > Are there any opinions on this from other Collections experts? > >>>> http://cr.openjdk.java.net/~mduigou/4802647/0/webrev/ Shouldn't the test include all collections included with the JDK? Any override of these methods could repeat the same (bad) behavior. Jason From darryl.mocek at oracle.com Wed Nov 30 22:16:36 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Wed, 30 Nov 2011 14:16:36 -0800 Subject: Code Review Request for Bug #7069190 Message-ID: <4ED6AB44.5040108@oracle.com> Hello. Please review this patch to fix the getting of the user's home setting using System.getProperty("user.home") on UNIX's. The previous implementation used getpwuid, which didn't allow the user to set the value in the environment. Webrev, can be found here: http://cr.openjdk.java.net/~darryl/7069190/webrev.00 Thanks, Darryl From darryl.mocek at oracle.com Wed Nov 30 22:23:12 2011 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Wed, 30 Nov 2011 14:23:12 -0800 Subject: Code Review Request for Bug #7069190 In-Reply-To: <4ED6AB44.5040108@oracle.com> References: <4ED6AB44.5040108@oracle.com> Message-ID: <4ED6ACD0.1020300@oracle.com> Wrong webrev link. Here's the correct one: http://cr.openjdk.java.net/~dmocek/7069190/webrev.00 Darryl On 11/30/2011 02:16 PM, Darryl Mocek wrote: > Hello. Please review this patch to fix the getting of the user's home > setting using System.getProperty("user.home") on UNIX's. The previous > implementation used getpwuid, which didn't allow the user to set the > value in the environment. > > Webrev, can be found here: > http://cr.openjdk.java.net/~darryl/7069190/webrev.00 > > Thanks, > Darryl From chris.hegarty at oracle.com Wed Nov 30 22:34:17 2011 From: chris.hegarty at oracle.com (chris hegarty) Date: Wed, 30 Nov 2011 22:34:17 +0000 Subject: 7116722: Miscellaneous warnings sun.misc ( and related classes ) In-Reply-To: <8B0B8C27-FBF0-4461-9FEC-E41C94682D04@oracle.com> References: <4ED65AEB.60200@oracle.com> <8B0B8C27-FBF0-4461-9FEC-E41C94682D04@oracle.com> Message-ID: <4ED6AF69.9020605@oracle.com> Thanks for all the feedback. changes: - use diamond in JarIndex (style issue) - sun.misc.Service -> java.util.ServiceLoader in InetAddress and HttpServerProvider - ExtensionDependency: suppress unchecked on declaration/assignment http://cr.openjdk.java.net/~chegar/7116722/webrev.01/webrev/ -Chris. On 30/11/2011 19:02, Lance Andersen - Oracle wrote: > Hi Chris, > > Do you want to use diamond reference on lines 81, 82 of jarindex.java? > > In Signal.java, line 203, i do not think you need new Integer() any longer? > > Other than that it looks good > > Best > Lance > > > On Nov 30, 2011, at 11:33 AM, Chris Hegarty wrote: > >> I started to look at the reason why we suppressed unchecked warning >> for sun.misc.Service in a few places, and this lead me into some other >> sun.misc classes. Here's a change that fixes a few warnings in this area. >> >> http://cr.openjdk.java.net/~chegar/7116722/webrev.00/webrev/ >> >> -Chris. > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From xueming.shen at oracle.com Wed Nov 30 23:23:32 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 30 Nov 2011 15:23:32 -0800 Subject: Code Review Request for Bug #7069190 In-Reply-To: <4ED6ACD0.1020300@oracle.com> References: <4ED6AB44.5040108@oracle.com> <4ED6ACD0.1020300@oracle.com> Message-ID: <4ED6BAF4.6020403@oracle.com> (1) you might need to consider the use scenario of an unset HOME env (2) it appears to be an in-compatible change if the values from getpwuid and from HOME are different (understood this is what you want to address), in which I think might need a CCC review (for the possible in-compatible change of behavior) -Sherman On 11/30/2011 2:23 PM, Darryl Mocek wrote: > Wrong webrev link. Here's the correct one: > http://cr.openjdk.java.net/~dmocek/7069190/webrev.00 > > Darryl > > On 11/30/2011 02:16 PM, Darryl Mocek wrote: >> Hello. Please review this patch to fix the getting of the user's >> home setting using System.getProperty("user.home") on UNIX's. The >> previous implementation used getpwuid, which didn't allow the user to >> set the value in the environment. >> >> Webrev, can be found here: >> http://cr.openjdk.java.net/~darryl/7069190/webrev.00 >> >> Thanks, >> Darryl From kurt at intricatesoftware.com Thu Nov 10 03:09:39 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Thu, 10 Nov 2011 03:09:39 -0000 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EBA336F.9060004@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EB106E5.9060706@linux.vnet.ibm.com> <4EB122BE.5090302@oracle.com> <4EB12BF4.9010805@linux.vnet.ibm.com> <4EB15356.9080209@oracle.com> <4EB23FD5.60108@linux.vnet.ibm.com> <4EB3664C.1050908@oracle.com> <4EB36FD3.3030306@oracle.com> <4EB37782.9010507@oracle.com> <4EBA336F.9060004@linux.vnet.ibm.com> Message-ID: <4EBB4062.8050403@intricatesoftware.com> On 11/09/11 03:01, Jonathan Lu wrote: > On 11/04/2011 01:26 PM, David Holmes wrote: >> On 4/11/2011 2:53 PM, David Holmes wrote: >>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: >>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu >>>> 10.03. The difference still exists. >>>> >>>> Solaris 10: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:04:45 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 13:04:53 JST 2011 >>>> >>>> Ubuntu 10.04: >>>> $ unset TZ >>>> $ date >>>> Fri Nov 4 13:05:50 JST 2011 >>>> $ TZ="" date >>>> Fri Nov 4 04:05:55 UTC 2011 >>>> >>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris >>>> still looks up the system default. >>> >>> I have to take back my comment regarding this not seeming to be platform >>> specific code - it is highly platform specific! It seems that on Linux >>> we are happy to report a TZ of "" but not so on Solaris. I presume this >>> is an attempt to keep Java's use of TZ consistent with how other apps >>> handle it on that platform. (environ(5) gives a little insight on >>> Solaris as to how TZ is used.) >>> >>> So the key thing here is to not disturb the existing behaviour on either >>> linux or Solaris - which suggests the original patch. That said I'm not >>> convinced - given this is so platform specific - that simply treating >>> non-linux the same as Solaris is a reasonable thing to do. I think it >>> would be useful to see what the BSD/OSX port(s) had to do with this code >>> - if anything. >> >> To answer my own queries BSD/OSX does >> >> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) >> 512 if (tz == NULL) { >> 513 #else >> 514 #ifdef __solaris__ >> 515 if (tz == NULL || *tz == '\0') { >> 516 #endif >> 517 #endif >> >> so the suggested patch would at least not interfere. >> >> Anyway this needs input from other core-libs folk. I didn't intend to >> get quite so heavily involved. ;-) >> >> David >> ----- >> >> >> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: >>>>> Hi Masayoshi, >>>>> >>>>> I did find some references about date-time related functions / TZ >>>>> variables on Linux but got only a few about Solaris, so could not see >>>>> any differences between those two platforms about the changes >>>>> described in my patch. Have you got any links or references about >>>>> these differences? I'm interested in it and may update the patch again >>>>> after reading them. >>>>> >>>>> Thanks a lot! >>>>> - Jonathan >>>>> >>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: >>>>>> Hi Jonathan, >>>>>> >>>>>> IIRC, the difference came from some behavioral difference between the >>>>>> Linux and Solaris libc date-time functions and/or the date command, >>>>>> and TimeZone_md.c tries to follow the difference. But the code was >>>>>> written looooong ago. The difference may no longer exist. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: >>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: >>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: >>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: >>>>>>>>>> Hi core-libs-dev, >>>>>>>>>> >>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from >>>>>>>>>> line >>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too >>>>>>>>>> narrow, since it also works for some kind of OS which I'm >>>>>>>>>> currently >>>>>>>>>> working on, such as AIX. >>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave >>>>>>>>>> the >>>>>>>>>> "#else" to accommodate more conditions, see attachment >>>>>>>>>> 'patch.diff'. I >>>>>>>>>> think this may enhance the cross-platform ability, any ideas >>>>>>>>>> about >>>>>>>>>> this modification? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> - Jonathan Lu >>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the >>>>>>>>> mail >>>>>>>>> content directly. >>>>>>>>> >>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c >>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 >>>>>>>>> 19:06:53 >>>>>>>>> 2011 -0700 >>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 >>>>>>>>> 13:43:47 >>>>>>>>> 2011 +0800 >>>>>>>>> @@ -626,10 +626,8 @@ >>>>>>>>> #ifdef __linux__ >>>>>>>>> if (tz == NULL) { >>>>>>>>> #else >>>>>>>>> -#ifdef __solaris__ >>>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>>> #endif >>>>>>>>> -#endif >>>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>>> freetz = tz; >>>>>>>>> } >>>>>>>> >>>>>>>> I'm unclear why any of that code needs to be platform specific - is >>>>>>>> an empty TZ string somehow valid on linux? I would have thought the >>>>>>>> following would be platform neutral: >>>>>>>> >>>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>>> tz = getPlatformTimeZoneID(); >>>>>>>> freetz = tz; >>>>>>>> } >>>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at >>>>>>> all and returns '\0' when TZ was exported as empty string. After >>>>>>> more checking for both cases, I agree with you, nothing useful can >>>>>>> be retrieved from that environment variable. >>>>>>> So I changed the patch to this, >>>>>>> >>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c >>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 >>>>>>> 2011 -0700 >>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 >>>>>>> 2011 +0800 >>>>>>> @@ -623,13 +623,7 @@ >>>>>>> >>>>>>> tz = getenv("TZ"); >>>>>>> >>>>>>> -#ifdef __linux__ >>>>>>> - if (tz == NULL) { >>>>>>> -#else >>>>>>> -#ifdef __solaris__ >>>>>>> if (tz == NULL || *tz == '\0') { >>>>>>> -#endif >>>>>>> -#endif >>>>>>> tz = getPlatformTimeZoneID(); >>>>>>> freetz = tz; >>>>>>> } >>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Regards >>>>>>>>> - Jonathan Lu >>>>>>> Regards >>>>>>> >>>>>>> - Jonathan >>>>>>> >>>>> > Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > has some ideas about this issue. Hi Jonathan, The above email is a bit hard to follow due to the mixture of top and bottom replies. I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior which confirms the need for platform ifdef's in this code. Seems like you need to make the following change: -#ifdef __solaris__ +#if defined(__solaris__) || defined(__AIX__) or something similar to maintain compatibility. In general the approach taken for adding BSD support was to never assume you can change other supported code paths. If your architecture follows an existing code path behavior add it like I did above. Otherwise just create a #ifdef myarch section for it. Unifying or changing another architecture's code path requires access to the arch, research and confirmation that the change is ok. Typically this may be done by writing independent test programs and running them on each arch. Regards, -Kurt From kurt at intricatesoftware.com Mon Nov 14 18:22:42 2011 From: kurt at intricatesoftware.com (Kurt Miller) Date: Mon, 14 Nov 2011 18:22:42 -0000 Subject: Patch to expand tz checking scope in TimeZone_md.c In-Reply-To: <4EC0D3E1.6080807@linux.vnet.ibm.com> References: <4EB105D1.9020401@linux.vnet.ibm.com> <4EBB4062.8050403@intricatesoftware.com> <4EC0D3E1.6080807@linux.vnet.ibm.com> Message-ID: <201111141322.40010.kurt@intricatesoftware.com> On Monday 14 November 2011 03:40:01 am Jonathan Lu wrote: > Hi Kurt, > > On 11/10/2011 11:09 AM, Kurt Miller wrote: > > On 11/09/11 03:01, Jonathan Lu wrote: > >> On 11/04/2011 01:26 PM, David Holmes wrote: > >>> On 4/11/2011 2:53 PM, David Holmes wrote: > >>>> On 4/11/2011 2:13 PM, Masayoshi Okutsu wrote: > >>>>> Probably the difference isn't documented. I tried Solaris 10 and Ubuntu > >>>>> 10.03. The difference still exists. > >>>>> > >>>>> Solaris 10: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:04:45 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 13:04:53 JST 2011 > >>>>> > >>>>> Ubuntu 10.04: > >>>>> $ unset TZ > >>>>> $ date > >>>>> Fri Nov 4 13:05:50 JST 2011 > >>>>> $ TZ="" date > >>>>> Fri Nov 4 04:05:55 UTC 2011 > >>>>> > >>>>> When the TZ value is an empty string, Ubuntu uses UTC while Solaris > >>>>> still looks up the system default. > >>>> I have to take back my comment regarding this not seeming to be platform > >>>> specific code - it is highly platform specific! It seems that on Linux > >>>> we are happy to report a TZ of "" but not so on Solaris. I presume this > >>>> is an attempt to keep Java's use of TZ consistent with how other apps > >>>> handle it on that platform. (environ(5) gives a little insight on > >>>> Solaris as to how TZ is used.) > >>>> > >>>> So the key thing here is to not disturb the existing behaviour on either > >>>> linux or Solaris - which suggests the original patch. That said I'm not > >>>> convinced - given this is so platform specific - that simply treating > >>>> non-linux the same as Solaris is a reasonable thing to do. I think it > >>>> would be useful to see what the BSD/OSX port(s) had to do with this code > >>>> - if anything. > >>> To answer my own queries BSD/OSX does > >>> > >>> 511 #if defined(__linux__) || defined(_ALLBSD_SOURCE) > >>> 512 if (tz == NULL) { > >>> 513 #else > >>> 514 #ifdef __solaris__ > >>> 515 if (tz == NULL || *tz == '\0') { > >>> 516 #endif > >>> 517 #endif > >>> > >>> so the suggested patch would at least not interfere. > >>> > >>> Anyway this needs input from other core-libs folk. I didn't intend to > >>> get quite so heavily involved. ;-) > >>> > >>> David > >>> ----- > >>> > >>> > >>> > >>>> David > >>>> ----- > >>>> > >>>> > >>>>> Thanks, > >>>>> Masayoshi > >>>>> > >>>>> On 11/3/2011 4:16 PM, Jonathan Lu wrote: > >>>>>> Hi Masayoshi, > >>>>>> > >>>>>> I did find some references about date-time related functions / TZ > >>>>>> variables on Linux but got only a few about Solaris, so could not see > >>>>>> any differences between those two platforms about the changes > >>>>>> described in my patch. Have you got any links or references about > >>>>>> these differences? I'm interested in it and may update the patch again > >>>>>> after reading them. > >>>>>> > >>>>>> Thanks a lot! > >>>>>> - Jonathan > >>>>>> > >>>>>> On 11/02/2011 10:27 PM, Masayoshi Okutsu wrote: > >>>>>>> Hi Jonathan, > >>>>>>> > >>>>>>> IIRC, the difference came from some behavioral difference between the > >>>>>>> Linux and Solaris libc date-time functions and/or the date command, > >>>>>>> and TimeZone_md.c tries to follow the difference. But the code was > >>>>>>> written looooong ago. The difference may no longer exist. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Masayoshi > >>>>>>> > >>>>>>> On 11/2/2011 8:39 PM, Jonathan Lu wrote: > >>>>>>>> On 11/02/2011 07:00 PM, David Holmes wrote: > >>>>>>>>> On 2/11/2011 7:01 PM, Jonathan Lu wrote: > >>>>>>>>>> On 11/02/2011 04:56 PM, Jonathan Lu wrote: > >>>>>>>>>>> Hi core-libs-dev, > >>>>>>>>>>> > >>>>>>>>>>> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from > >>>>>>>>>>> line > >>>>>>>>>>> 626, I found that the scope of "#ifdef __solaris__" might be too > >>>>>>>>>>> narrow, since it also works for some kind of OS which I'm > >>>>>>>>>>> currently > >>>>>>>>>>> working on, such as AIX. > >>>>>>>>>>> So I suggest to just remove the '#ifdef __solaris__' and leave > >>>>>>>>>>> the > >>>>>>>>>>> "#else" to accommodate more conditions, see attachment > >>>>>>>>>>> 'patch.diff'. I > >>>>>>>>>>> think this may enhance the cross-platform ability, any ideas > >>>>>>>>>>> about > >>>>>>>>>>> this modification? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> - Jonathan Lu > >>>>>>>>>> I'm not sure why the attachment got filtered, here paste it to the > >>>>>>>>>> mail > >>>>>>>>>> content directly. > >>>>>>>>>> > >>>>>>>>>> diff -r 4788745572ef src/solaris/native/java/util/TimeZone_md.c > >>>>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Mon Oct 17 > >>>>>>>>>> 19:06:53 > >>>>>>>>>> 2011 -0700 > >>>>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 > >>>>>>>>>> 13:43:47 > >>>>>>>>>> 2011 +0800 > >>>>>>>>>> @@ -626,10 +626,8 @@ > >>>>>>>>>> #ifdef __linux__ > >>>>>>>>>> if (tz == NULL) { > >>>>>>>>>> #else > >>>>>>>>>> -#ifdef __solaris__ > >>>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>>> #endif > >>>>>>>>>> -#endif > >>>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>>> freetz = tz; > >>>>>>>>>> } > >>>>>>>>> I'm unclear why any of that code needs to be platform specific - is > >>>>>>>>> an empty TZ string somehow valid on linux? I would have thought the > >>>>>>>>> following would be platform neutral: > >>>>>>>>> > >>>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>>> freetz = tz; > >>>>>>>>> } > >>>>>>>>> > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> getenv("TZ") returns NULL when TZ environment variable is not set at > >>>>>>>> all and returns '\0' when TZ was exported as empty string. After > >>>>>>>> more checking for both cases, I agree with you, nothing useful can > >>>>>>>> be retrieved from that environment variable. > >>>>>>>> So I changed the patch to this, > >>>>>>>> > >>>>>>>> diff -r 7ab0d613cd1a src/solaris/native/java/util/TimeZone_md.c > >>>>>>>> --- a/src/solaris/native/java/util/TimeZone_md.c Thu Oct 20 10:32:47 > >>>>>>>> 2011 -0700 > >>>>>>>> +++ b/src/solaris/native/java/util/TimeZone_md.c Wed Nov 02 19:34:51 > >>>>>>>> 2011 +0800 > >>>>>>>> @@ -623,13 +623,7 @@ > >>>>>>>> > >>>>>>>> tz = getenv("TZ"); > >>>>>>>> > >>>>>>>> -#ifdef __linux__ > >>>>>>>> - if (tz == NULL) { > >>>>>>>> -#else > >>>>>>>> -#ifdef __solaris__ > >>>>>>>> if (tz == NULL || *tz == '\0') { > >>>>>>>> -#endif > >>>>>>>> -#endif > >>>>>>>> tz = getPlatformTimeZoneID(); > >>>>>>>> freetz = tz; > >>>>>>>> } > >>>>>>>> > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> - Jonathan Lu > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> - Jonathan > >>>>>>>> > >> Copy to bsd-port-dev and macosx-port-dev lists to see if anybody here > >> has some ideas about this issue. > > Hi Jonathan, > > > > The above email is a bit hard to follow due to the mixture of top and > > bottom replies. > > > > I can confirm that OpenBSD and Mac OS X 10.5.8 follow the Linux behavior > > which confirms the need for platform ifdef's in this code. > > > > Seems like you need to make the following change: > > > > -#ifdef __solaris__ > > +#if defined(__solaris__) || defined(__AIX__) > > > > or something similar to maintain compatibility. > > > > In general the approach taken for adding BSD support was to never > > assume you can change other supported code paths. If your architecture > > follows an existing code path behavior add it like I did above. > > Otherwise just create a #ifdef myarch section for it. > > > > But for this case, I think it is a good idea to leave a default code > path here. > Since in src/solaris/native/java/util/TimeZone_md.c starting from line > 624, the return value of getenv("TZ"); has to be tested afterward on any > platforms. > So to improve portability for OpenJDK, how about leaving Solaris style > checking as the default approach? Ah I see what you're getting at now. As a bsd-port only committer my opinion has limited value, but for what its worth I can give you my perspective on the issue. The code base is large and there are many places like this where unifying the behavior of different archs is the goal. Keeping with the non-configure approach where ifdef __MYARCH__ is used for differing behaviors then I see the ideal situation being that the porter/developer is required to make the correct choice for the new __MYARCH__ and no default be assumed. If a default behavior is assumed, which one do you pick? Also what happens when your done porting but many of the defaults don't match your new arch? I can tell you it is a lot of work to find the bits of code embedded into the jdk code base to fix when the TCK fails tests. I rather do that work up front and be forced to pick the correct behavior due to a failure to compile. For example, had this code compiled for you it is quite posible you would not have know that there are different behaviors to pick from and to select the correct one for you. Regards, -Kurt From neugens.limasoftware at gmail.com Tue Nov 29 02:05:22 2011 From: neugens.limasoftware at gmail.com (=?utf-8?B?bmV1Z2Vucy5saW1hc29mdHdhcmVAZ21haWwuY29t?=) Date: Tue, 29 Nov 2011 02:05:22 -0000 Subject: =?utf-8?B?UmU6IDxTd2luZyBEZXY+IEFkZCBMb29rJkZlZWwgc3VwcG9ydCBmb3IgQUlYIHBsYXRmb3Jt?= Message-ID: <4ed43de2.4713cc0a.2daf.1d8d@mx.google.com> The change looks good to me as well. Cheers, Mario Inviato da HTC ----- Reply message ----- Da: "Deven" Data: mar, nov 29, 2011 02:55 Oggetto: Add Look&Feel support for AIX platform A: "Neil Richards" Cc: "Java Core Libs" , , On 10/20/2011 11:10 PM, Neil Richards wrote: > On Tue, 2011-10-18 at 15:53 +0800, Sean Chou wrote: >> Hi all, >> >> >> This is a simple patch to add LookAndFeel support for AIX platform >> to help bring >> up GUI application. >> >> >> This is part of the series of AIX patches. >> -- >> Best Regards, >> Sean Chou >> >> > For ease of review, I've uploaded this suggested fix as a webrev [1]. > > The change looks good to me. > > Regards, Neil > > [1] http://cr.openjdk.java.net/~ngmr/ojdk-167/webrev.00/index.html Hello, any more comments on this topic?