Re: RFR(M, v10): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo
Dmitry,
Instead of hardcoding the field offsets, you can use InstanceKlass::find_field
and fieldDescriptor::offset to find the offset at runtime.
Thanks,
/Staffan
On 31 maj 2015, at 13:43, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Everyone,
Please take a look at new version of the fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.10/
Changes (to previous version) are in
Finalizer.java and diagnosticCommand.cpp
This version copy data from Map.Entry to array of
FinalizerHistogramEntry instances then,
VM prints content of this array.
-Dmitry
On 2015-05-28 21:06, Mandy Chung wrote:
On 05/28/2015 07:35 AM, Peter Levart wrote:
Hi Mandy,
On 05/27/2015 03:32 PM, Mandy Chung wrote:
Taking it further - is it simpler to return String[] of all
classnames including the duplicated ones and have the VM do the
count? Are you concerned with the size of the String[]?
Yes, the histogram is much smaller than the list of all instances.
There can be millions of instances waiting in finalizer queue, but
only a few distinct classes.
Do you happen to know what libraries are the major contributors to these
millions of finalizers?
It has been strongly recommended to avoid finalizers (see Effective Java
Item 7). I'm not surprised that existing code is still using
finalizers while we should really encourage them to migrate away from it.
What could be done in Java to simplify things in native code but still
not format the output is to convert the array of Map.Entry(s) into an
Object[] array of alternating {String, int[], String, int[], }
Would this simplify native code for the price of a little extra work
in Java? The sizes of old and new arrays are not big (# of distinct
classes of finalizable objects in the queue).
I also prefer writing in Java and writing less native code (much
simplified). It's an interface that we have to agree upon and keep it
simple. Having the returned Object[] as alternate String and int[] is a
reasonable compromise.
ReferenceQueue.java - you can move @SuppressWarning from the method to
just the field variable rn
@SuppressWarnings(unchecked)
Reference? extends T rn = r.next;
Finalizer.java
It's better to rename printFinalizationQueue as it inspects the
finalizer reference queue (maybe getFinalizerHistogram?). Can you move
this method to the end of this class and add the comment saying that
this is invoked by VM for jcmd -finalizerinfo support and @return to
describe the returned content. I also think you can remove
@SuppressWarnings for this method.
Mandy
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
On 06/01/2015 10:32 AM, Ulf Zibis wrote: Hi, Am 31.05.2015 um 18:03 schrieb Ivan Gerasimov: On 31.05.2015 18:54, Ivan Gerasimov wrote: I fixed the code and added the case to the regression test in the new webrev. Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Shoudn't the user be informed via javadoc about the risk of an OutOfMemoryError, just from illegal arguments of this method? Example: this.value.length() = 100 target.value.length() = 200 replacement.value.length() = 50 results in: ...no replacements made, since target.value.length() this.value.length() and 1st indexOf returns -1... if 1st indexOf returns = 0, then this.value.length() = target.value.length() and the only way to get negative newLenHint is via an overflow indicating that a String with length() Integer.MAX_VALUE would be required to hold the result, which is impossible. We don't have a special StringTooBigException. OOME is the best approximation here. IllegalArgumentException is another option, but seems to be to general in this case. What happens when regexp based replace is fed with such huge strings? I had to set the max. heap size to 14Gbytes to get the answer that was not an OOME caused by not enough heap space: char[] chars = new char[1 + (1 30)]; chars[0] = 'a'; String big = new String(chars); big.replace(a, big); Exception in thread main java.lang.OutOfMemoryError at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:517) at java.lang.StringBuilder.append(StringBuilder.java:175) at java.util.regex.Matcher.appendTail(Matcher.java:1122) at java.util.regex.Matcher.replaceAll(Matcher.java:1169) at TestReplace.replace(TestReplace.java:11) at TestReplace.main(TestReplace.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) Regards, Peter newLenHint = -500 -- OutOfMemoryError In other words, is this a good reason to throw such an Error? Little nit: Indentation for line continuation should be 8 spaces. -Ulf
Re: JEP 254: Compact Strings
Hi Aleksey, While it's true that the denser format will require fewer cachelines, my experience is that most strings are smaller than a single cacheline worth of storage, maybe two lines in some cases; there's just a ton of them in the heap. So the heap footprint should be substantially reduced, but I'm not sure the cache pollution will be significantly reduced. There's currently no vectorization of char[] scanning (or any vectorization other than memcpy for that matter) - are you referring to the recent Intel contributions here or there's a plan to further improve vectorization in time for this JEP? Just curious. I agree that string fusion is separate from this change, and we've discussed this before. It just seems to me like that's a bigger perf problem today since even tiny/small strings (very common, IME) incur the indirection and bloat overhead, so would have liked to see that addressed first. If you're saying that's fully on valhalla's plate, ok, but I haven't seen anything proposed there yet. Thanks sent from my phone On Jun 1, 2015 4:50 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 05/18/2015 05:35 PM, Vitaly Davidovich wrote: This part is a bit unclear for the proposed changes. While it's true that single byte encoding will be denser than two byte, most string ops end up walking the backing store linearly; prefetch (either implicit h/w or software-assisted) could hide the memory access latency. It will still pollute the caches though, and generally incur more instructions to be executed (e.g. think about the vectorized scan of the char[] array -- the compressed version will take 2x less instructions). Personally, what I'd like to see is fusing storage of String with its backing data, irrespective of encoding (i.e. removing the indirection to fetch the char[] or byte[]). This is not the target for this JEP, and the groundwork for String-char[] fusion is handled elsewhere (I put my hopes at Valhalla that will explore the exact path to add the exotic object shapes into the runtime). String-char[] fusion neither conflicts with the Compact String optimization, nor provides the alternative. Removing the excess headers from backing char[] array would solve the static overhead in Strings, while the String compaction would further compact the backing storage. Thanks, -Aleksey.
Re: JEP 254: Compact Strings
On 05/18/2015 05:35 PM, Vitaly Davidovich wrote: This part is a bit unclear for the proposed changes. While it's true that single byte encoding will be denser than two byte, most string ops end up walking the backing store linearly; prefetch (either implicit h/w or software-assisted) could hide the memory access latency. It will still pollute the caches though, and generally incur more instructions to be executed (e.g. think about the vectorized scan of the char[] array -- the compressed version will take 2x less instructions). Personally, what I'd like to see is fusing storage of String with its backing data, irrespective of encoding (i.e. removing the indirection to fetch the char[] or byte[]). This is not the target for this JEP, and the groundwork for String-char[] fusion is handled elsewhere (I put my hopes at Valhalla that will explore the exact path to add the exotic object shapes into the runtime). String-char[] fusion neither conflicts with the Compact String optimization, nor provides the alternative. Removing the excess headers from backing char[] array would solve the static overhead in Strings, while the String compaction would further compact the backing storage. Thanks, -Aleksey.
Re: JEP 132: More-prompt finalization
Hi Moh, On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote: The problems start with the ReferenceQueue object and the heavy synchronization in it. Consider structures like j.u.WeakHashMap that need to expunge entries. If such structures are made somewhat concurrent, the lock in ReferenceQueue starts to become a serious problem: -In structures that are concurrent at the entry level (like jdk 8’s ConcurrentHashMap), if methods like get() or put() try to expunge, the lock in ReferenceQueue renders the structures non-concurrent. The presented prototype changes the implementation of ReferenceQueue. It doesn't use a lock any more for enqueu-ing when there are no waiters and never for poll-ing. ReferenceQueue.poll() is a single volatile read when queue is empty and a read followed by CAS when it is not (with retries when contended). If there is a desire and new API could be extended, the method like the following: IteratorReference? extends T pollChunk(int maxChunkSize); ...could return a chunk of enqueued references (or an empty iterator) so that the reduced number of CAS instructions per de-queued reference could be traded for the greater probability of retries because of contention. -In structures that are multi-reader-single-writer locked, read methods cannot expunge (because they have to promote to a writer), but they can’t even check the queue, because that turns the multi-reader structure into a synchronized one. By checking you mean poll() which also de-queues a reference if available? What do you do when this happens. Would you need a peek() method maybe? -In addition to expunge calls contending on the ReferenceQueue lock, ReferenceHandler thread can also contend on the same lock. That's right. And in the presented prototype, this is minimized by allowing ReferenceHandler thread to enqueue a chunk of pre-prepared references in one go, minimizing the need to frequently notify any possible waiters via a lock.notifyAll(). -There is no fast clear() method on ReferenceQueue. That would be quite useful on a resize event. This would be easy to implement if new API could be added. The above issues forced us to have a dedicated thread that does periodic expunging of References. This works ok under light load, but can fall behind under heavy load. Because of the overhead/bottleneck of the reference processing I assume. It would be great if you could check whether the prototype in webrev.02 improves your situation. It should be simple. Just compile the sources and prepend the resulting classes to the bootclasspath of the JDK. Regards, Peter Thanks Moh @Moh Can you elaborate some more on what twists were necessary or what problems you had?
Re: JEP 254: Compact Strings
(getting back to this) Hi Jeremy, On 05/16/2015 03:34 AM, Jeremy Manson wrote: So, I'm pretty dubious, mostly because of the risks mentioned in the JEP. If you need a flag-check and two code paths for every String method, that's going to make the String class more slow and bloated, and make it very difficult for the JIT compiler to do its job inlining and intrinsifying calls to String methods. Yes, we know that's a potential problem, e.g. outlined here: http://cr.openjdk.java.net/~shade/density/equals.txt The hope is that the string coder check would be amortized by the substantial performance improvement with the ubiquitous Latin1 (optimized) operations. Also, getting a few code generation quirks kicked out may further offset the perceived performance costs of doing this (you can do such a trick every so often, but not all the time). The proposed change here has the potential of doing the opposite with most String operations - trading off less GC overhead for more mutator cost. But String operations are a pretty big chunk of CPU time, on the whole. The thing is, many mutator ops on Strings are also improved, because the data become more easily cacheable and/or require less steps to complete (think vectorization that takes 2x less instructions). Does anyone really have a sense of how to make this kind of decision? The JEP seems mostly to be hoping that other organizations will do the testing for you. It is not true that JEP hopes to have other organizations to do testing for it. The JEP tries to illuminate that this is a performance-sensitive change, so early testing and feedback is very appreciated. So, if you have the String-intensive workloads in your org, can you try and run the prototype JDK against it? Our early runs on our workloads of interest show the appealing improvements. That is, the decision to integrate this is not done yet, as we don't have the complete performance picture and/or fully-tested prototype. In other words, there are quite a few blank spots to fill out. Your data may be the part of that picture when we decide to integrate in JDK 9. (I agree that it is worth doing some experimentation in this area, but I wanted to say this early, because if I could reach back in time and tell you *not* to make the substring change, I would. We seriously considered simply backing it out locally, but it would have been a lot of effort for us to maintain that kind of patch, and we didn't want our performance tradeoffs to be that much different from the stock JDK's.) This is your golden ticket: if you come back with concrete data in your hands saying that the particular tradeoff the JEP made is not sensible for your applications, it would be considered in the decision to integrate. But, it should be a real data and/or contrived benchmark simulating the real-world scenario, not just theoretical appeals -- we know how misguided those can get. Thanks, -Aleksey
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
Hi Ivan,
nitpicking mode=on/
Le 31 mai 2015 17:54:35 CEST, Ivan Gerasimov ivan.gerasi...@oracle.com a
écrit :
Hi Remi!
On 31.05.2015 11:43, Remi Forax wrote:
I agree with the others the code is more readable.
There is a slightly difference between the current behavior and the
behavior of the proposed code,
foo.replace(bar, null)
should throw a NPE because replacement is null but the proposed code
will return foo
because replacement.toString() is called after the short-circuit test
(j 0).
Yes, you're right, thanks for catching it!
And the regression test should have caught that, but I only had
a.replace(a, null) there, which passed.
I fixed the code and added the case to the regression test in the new
webrev.
so the first part of the code should be:
String starget = target.toString(); // implict nullcheck
String srepl = replacement.toString(); // implicit nullcheck
int j = indexOf(starget);
if (j 0) {
return this;
}
...
also 'i' can be initialized just before the 'do', there is no point
to
initialize it before.
To finish, the two 'final' are useless here but i suppose it's a
matter of style :)
I moved declaration of i just to save a line. I don't think it
decreased performance.
I don't think so too.
It decrease readability, when you read the code of the loop you have to scroll
up to find the initialization of 'i' like in plain old good C.
Declaring the 'value' variable final was suggested by Martin, and I
think it is reasonable (see
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032601.html).
The other variable is final just for symmetry :)
Either i read the code in an IDE and local variables and fields do not have the
same color or i read diff and in that case fields are usually not visible.
For me, final on local variable is just noise. But as i said it's a matter of
taste.
Sincerely yours,
Ivan
cheers,
Rémi
cheers,
Rémi
On 05/31/2015 04:19 AM, Ivan Gerasimov wrote:
Hi everyone!
Here's another webrev, in which replace() is implemented with
StringBuilder.
On my benchmark it is almost as fast as the version backed with
arrays, but this variant is much shorter.
Credits to Sherman for combining the general algorithm with the case
of empty target.
Comments, further suggestions are welcome!
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058779
WEBREV: http://cr.openjdk.java.net/~igerasim/8058779/04/webrev/
Sincerely yours,
Ivan
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
Hi, Am 31.05.2015 um 18:03 schrieb Ivan Gerasimov: On 31.05.2015 18:54, Ivan Gerasimov wrote: I fixed the code and added the case to the regression test in the new webrev. Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Shoudn't the user be informed via javadoc about the risk of an OutOfMemoryError, just from illegal arguments of this method? Example: this.value.length() = 100 target.value.length() = 200 replacement.value.length() = 50 results in: newLenHint = -500 -- OutOfMemoryError In other words, is this a good reason to throw such an Error? Little nit: Indentation for line continuation should be 8 spaces. -Ulf
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Much better. For the test can you use RandomFactory recently added to the test library? Paul.
Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
Hi Vladmir It seems we have only this bug that manifests the problem. As I understand, this is a product issue, not test. -Konstantin On 29.05.2015 14:49, Vladimir Ivanov wrote: What do you mean by ignore code cache overflow? Do you mean I should fix the test to ignore these errors or should I leave this test unfixed because it is a product related issue? The former. How reliable the test is if it ignores NoSuchMethodException VirtualMachineError? Are there other manifestations of the problem? Best regards, Vladimir Ivanov On 28.05.2015 21:22, Vladimir Ivanov wrote: Got it, thanks. Can we ignore errors caused by code cache overflow for now? Best regards, Vladimir Ivanov On 5/28/15 12:03 PM, Konstantin Shefov wrote: Vladimir, This fix is not for timeout issue, this fix is for java.lang.VirtualMachineError: out of space in CodeCache for adapters. Timeout issue is other bug and should be filed separately. I do not know why SQE added RULES with timeout to this bug. By the way, if -Xcomp is set on JDK 8u, test works if not more than one iteration is allowed. The same thing was for JDK 9 until JDK-8046809 had been fixed. -Konstantin On 27.05.2015 19:54, Vladimir Ivanov wrote: Have you tried to reduce iteration granularity? Probably, checking execution duration on every test case is more robust. Best regards, Vladimir Ivanov On 5/27/15 5:50 PM, Konstantin Shefov wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8062904 Webrev is http://cr.openjdk.java.net/~kshefov/8062904/webrev.01/ Test fails only against JDK 8u and passes against JDK 9. Thanks -Konstantin
RE: JEP 132: More-prompt finalization
I read the code in the prototype and I liked what I saw (even excited!), which is the reason I spoke up. On the API side, I was mulling over what the addition of bulk methods and even just a size() method could do to help and it struck me: the JDK has come a long way since 1.0 and there are now fully fledged, well thought out queue implementations. Is there a reason ReferenceQueue can't be upgraded to be one of those (api and/or implementation wise)? I hope given all the reasoning that's gone into the canonical queue implementations there wouldn't be a lot of reason to debate their usefulness. But just as an example, let's consider having access to a fast, roughly accurate ReferenceQueue.size() method for the hash structures use case. A hash structure has to find the freed instances and remove them. If size() returns a large portion of the total entries, it would be better to re-hash the structure and bulk clear the references instead. Unfortunately, I don't have a great benchmark, so I can't run the prototype quickly. I'll have to put some time aside to figure out a good way to represent the situation before I can come back with meaningful numbers. Thanks Moh From: Peter Levart [mailto:peter.lev...@gmail.com] Sent: Monday, June 01, 2015 5:04 AM To: Rezaei, Mohammad A. [Tech] Cc: 'hotspot-gc-...@openjdk.java.net openjdk.java.net'; 'core-libs-dev@openjdk.java.net' Subject: Re: JEP 132: More-prompt finalization Hi Moh, On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote: The problems start with the ReferenceQueue object and the heavy synchronization in it. Consider structures like j.u.WeakHashMap that need to expunge entries. If such structures are made somewhat concurrent, the lock in ReferenceQueue starts to become a serious problem: - In structures that are concurrent at the entry level (like jdk 8's ConcurrentHashMap), if methods like get() or put() try to expunge, the lock in ReferenceQueue renders the structures non-concurrent. The presented prototype changes the implementation of ReferenceQueue. It doesn't use a lock any more for enqueu-ing when there are no waiters and never for poll-ing. ReferenceQueue.poll() is a single volatile read when queue is empty and a read followed by CAS when it is not (with retries when contended). If there is a desire and new API could be extended, the method like the following: IteratorReference? extends T pollChunk(int maxChunkSize); ...could return a chunk of enqueued references (or an empty iterator) so that the reduced number of CAS instructions per de-queued reference could be traded for the greater probability of retries because of contention. - In structures that are multi-reader-single-writer locked, read methods cannot expunge (because they have to promote to a writer), but they can't even check the queue, because that turns the multi-reader structure into a synchronized one. By checking you mean poll() which also de-queues a reference if available? What do you do when this happens. Would you need a peek() method maybe? - In addition to expunge calls contending on the ReferenceQueue lock, ReferenceHandler thread can also contend on the same lock. That's right. And in the presented prototype, this is minimized by allowing ReferenceHandler thread to enqueue a chunk of pre-prepared references in one go, minimizing the need to frequently notify any possible waiters via a lock.notifyAll(). - There is no fast clear() method on ReferenceQueue. That would be quite useful on a resize event. This would be easy to implement if new API could be added. The above issues forced us to have a dedicated thread that does periodic expunging of References. This works ok under light load, but can fall behind under heavy load. Because of the overhead/bottleneck of the reference processing I assume. It would be great if you could check whether the prototype in webrev.02 improves your situation. It should be simple. Just compile the sources and prepend the resulting classes to the bootclasspath of the JDK. Regards, Peter Thanks Moh @Moh Can you elaborate some more on what twists were necessary or what problems you had?
RFR 9: 8081565 : javac lint warnings in jdk testlibrary
Please review test library changes to remove javac lint warnings. And 1 test that incorrectly used try-with-resources. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-testlint-8081565/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081565 Thanks, Roger
Re: JEP 254: Compact Strings
On 06/01/2015 03:54 PM, Vitaly Davidovich wrote: While it's true that the denser format will require fewer cachelines, my experience is that most strings are smaller than a single cacheline worth of storage, maybe two lines in some cases; there's just a ton of them in the heap. So the heap footprint should be substantially reduced, but I'm not sure the cache pollution will be significantly reduced. This calculation assumes object allocations are granular to the cache lines. They are not: if String takes less space within the cache line, it allows *more* object data to be squeezed there. In other words, with compact Strings, the entire dataset can take less cache lines, thus improving performance. There's currently no vectorization of char[] scanning (or any vectorization other than memcpy for that matter) - are you referring to the recent Intel contributions here or there's a plan to further improve vectorization in time for this JEP? Just curious. String methods are intensely intrinsified (and vectorized in those implementations). String::equals, String::compareTo, and some encoding/decoding come to mind. I really, really invite you to read the collateral materials from the JEP, where we explored quite a few performance characteristics already. Thanks, -Aleksey.
Re: JEP 254: Compact Strings
My calculation doesn't assume cacheline granularity; I'm looking at strictly the strings. What's allocated next to/around them is completely arbitrary, circumstantial, uncontrollable to a large extent, and often not repeatable. If you're claiming that some second or even third order locality effects will be measurable, I don't know how :). I'm sure there will be some as theoretically it's possible, but it'll be hard to demonstrate that on anything other than specially crafted microbenchmarks. Ok, you're talking about some string intrinsics and not general char[] being vectorized - fair enough. sent from my phone On Jun 1, 2015 9:31 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 06/01/2015 03:54 PM, Vitaly Davidovich wrote: While it's true that the denser format will require fewer cachelines, my experience is that most strings are smaller than a single cacheline worth of storage, maybe two lines in some cases; there's just a ton of them in the heap. So the heap footprint should be substantially reduced, but I'm not sure the cache pollution will be significantly reduced. This calculation assumes object allocations are granular to the cache lines. They are not: if String takes less space within the cache line, it allows *more* object data to be squeezed there. In other words, with compact Strings, the entire dataset can take less cache lines, thus improving performance. There's currently no vectorization of char[] scanning (or any vectorization other than memcpy for that matter) - are you referring to the recent Intel contributions here or there's a plan to further improve vectorization in time for this JEP? Just curious. String methods are intensely intrinsified (and vectorized in those implementations). String::equals, String::compareTo, and some encoding/decoding come to mind. I really, really invite you to read the collateral materials from the JEP, where we explored quite a few performance characteristics already. Thanks, -Aleksey.
RFR 9: 8081566: java/lang/ProcessHandle/InfoTest.java failed on case sensitive command
Please review this testbug fix to correctly check the reported command name. On Windows the command filename may differ only by case and should be checked to see if they are the same file, not just the same string. webrev: http://cr.openjdk.java.net/~rriggs/webrev-infotest-8081566/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081566 Thanks, Roger
Re: RFR 9: 8081566: java/lang/ProcessHandle/InfoTest.java failed on case sensitive command
Hi Roger, The changes all seem reasonable Best Lance On Jun 1, 2015, at 9:57 AM, Roger Riggs roger.ri...@oracle.com wrote: Please review this testbug fix to correctly check the reported command name. On Windows the command filename may differ only by case and should be checked to see if they are the same file, not just the same string. webrev: http://cr.openjdk.java.net/~rriggs/webrev-infotest-8081566/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081566 Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR 9: 8081565 : javac lint warnings in jdk testlibrary
Hi Roger, These changes also look fine Best Lance On Jun 1, 2015, at 9:32 AM, Roger Riggs roger.ri...@oracle.com wrote: Please review test library changes to remove javac lint warnings. And 1 test that incorrectly used try-with-resources. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-testlint-8081565/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081565 Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR 9: 8081566: java/lang/ProcessHandle/InfoTest.java failed on case sensitive command
On 01/06/2015 14:57, Roger Riggs wrote: Please review this testbug fix to correctly check the reported command name. On Windows the command filename may differ only by case and should be checked to see if they are the same file, not just the same string. File path comparison is case insensitive on Windows so equals would work if the path Strings were obtaining from actual file paths. This doesn't seem to be case here so using isSameFile make sense. -Alan.
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
On 01.06.2015 11:33, Paul Sandoz wrote: On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Much better. For the test can you use RandomFactory recently added to the test library? Sure. Here the updated webrev with this change and a few other minor changes. http://cr.openjdk.java.net/~igerasim/8058779/06/webrev/ The changes are: - move declaration of i below, - indent .append(), - use RandomFactory in the test, - extend number of test cases with null input. Do you think it's ready to go? Sincerely yours, Ivan Paul.
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
Ivan, The code looks fine for me. Just wonder what's the motivation of using the newStringUnsafe() in the test case. Simply to save the char[] copy to speed up the test? I don't think we really care about it here, right? -Sherman On 06/01/2015 11:53 AM, Ivan Gerasimov wrote: On 01.06.2015 11:33, Paul Sandoz wrote: On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Much better. For the test can you use RandomFactory recently added to the test library? Sure. Here the updated webrev with this change and a few other minor changes. http://cr.openjdk.java.net/~igerasim/8058779/06/webrev/ The changes are: - move declaration of i below, - indent .append(), - use RandomFactory in the test, - extend number of test cases with null input. Do you think it's ready to go? Sincerely yours, Ivan Paul.
RFR 9: 8081567 : java/lang/ProcessHandle/InfoTest.java failed Cannot run program whoami
Please review a change to report the user/owner in ProcessHandle.info to have the same form for the owner identification as provided by java.nio.Files. On Windows it includes the domain with the user name. The test is updated to remove a dependency on the OS command whoami and instead compare the users process with the owner of a file created by the process improving portability. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-whoami-8081567/ Issue: https://bugs.openjdk.java.net/browse/JDK-8081567 Thanks, Roger
JDK 9 RFR of JDK-8075551: Add tiered testing definitions to the jaxp repo
Hello, Please review these changes to regularize the jaxp regression testing infrastructure with the JDK tiered testing policy. [1] JDK-8075551: Add tiered testing definitions to the jaxp repo http://cr.openjdk.java.net/~darcy/8075551.0/ In brief, testing tiers are defined (with an empty tier 1 for jaxp) and an empty problem list is added. When analogous changes are made in all the repositories, it will be possible to use a jtreg command like jtreg -exclude:ProblemList.txt [... other options...] :tier$N for any repo. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
Re: JDK 9 RFR of JDK-8075551: Add tiered testing definitions to the jaxp repo
On 6/1/2015 3:16 PM, joe darcy wrote: Hello, Please review these changes to regularize the jaxp regression testing infrastructure with the JDK tiered testing policy. [1] JDK-8075551: Add tiered testing definitions to the jaxp repo http://cr.openjdk.java.net/~darcy/8075551.0/ In brief, testing tiers are defined (with an empty tier 1 for jaxp) and an empty problem list is added. The change looks good to me. When analogous changes are made in all the repositories, it will be possible to use a jtreg command like jtreg -exclude:ProblemList.txt [... other options...] :tier$N How does it work in JPRT, something like -testset core:tier$2? Thanks, Joe for any repo. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html
Re: JDK 9 RFR of JDK-8075551: Add tiered testing definitions to the jaxp repo
On 6/1/2015 6:15 PM, huizhe wang wrote: On 6/1/2015 3:16 PM, joe darcy wrote: Hello, Please review these changes to regularize the jaxp regression testing infrastructure with the JDK tiered testing policy. [1] JDK-8075551: Add tiered testing definitions to the jaxp repo http://cr.openjdk.java.net/~darcy/8075551.0/ In brief, testing tiers are defined (with an empty tier 1 for jaxp) and an empty problem list is added. The change looks good to me. When analogous changes are made in all the repositories, it will be possible to use a jtreg command like jtreg -exclude:ProblemList.txt [... other options...] :tier$N How does it work in JPRT, something like -testset core:tier$2? I'm also very interested on an answer to this thanks Alejandro Thanks, Joe for any repo. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html -- Alejandro
