Thank you David for your reply!
On 14.03.2014 8:56, David Holmes wrote:
Hi Ivan,
I think we need to apply the brakes here and back up a bit :)
First of all these aren't typo fixes they are spec changes and they
will need to go through CCC for approval.
Yes, sure. I haven't done that
Hi Ivan,
On 14/03/2014 5:05 PM, Ivan Gerasimov wrote:
Thank you David for your reply!
On 14.03.2014 8:56, David Holmes wrote:
Hi Ivan,
I think we need to apply the brakes here and back up a bit :)
First of all these aren't typo fixes they are spec changes and they
will need to go through
On 03/14/2014 01:29 AM, Brian Burkhalter wrote:
On Mar 12, 2014, at 2:08 AM, Peter Levart wrote:
Huh! This is a ThreadLocalRandom anti-pattern. Thou should not use a
ThreadLocalRandom instance in a thread that did not obtain it via a
call to ThreadLocalRandom.current()…
Good point.
You
On 03/14/2014 01:32 AM, Brian Burkhalter wrote:
On Mar 12, 2014, at 1:45 AM, Peter Levart wrote:
What would the following cost?
private transient String stringCache;
public String toString() {
[…]
This version did not show any significant difference in the benchmark
results
Thanks David!
On 14.03.2014 12:31, David Holmes wrote:
Second point is that the condition fromIndex = size() is already
captured by the condition if {@code fromIndex} or {@code toIndex} is
out of range. By definition fromIndex is out-of-range if it is 0 or
= size(). So I don't see any
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
One thing I noticed is that some methods I mentioned above
(List.subList(), Arrays.sort(), etc) throw IllegalArgumentException
when fromIndex toIndex, not IndexOutOfBoundException.
Wouldn't it be more correct to adopt this into removeRange() too?
Hi,
Without getting into the details, make sure that the behavior seen by
applications is not changed without careful and exhaustive review.
Usually, the specification is updated to match the existing long standing
behavior including exceptions and edge cases.
Roger
On 3/14/14 6:50 AM,
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
One thing I noticed is that some methods I mentioned above
(List.subList(), Arrays.sort(), etc) throw IllegalArgumentException
when fromIndex toIndex, not
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8037210
953 lines changed: 425 ins; 217 del; 311 mod
This is a massive cleanup of JSR292 code to replace char-based
description of basic types by numeric constants.
Contributed-by:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8037209
440 lines changed: 313 ins; 67 del; 60 mod
This is a cleanup of JSR292 code to improve bytecode assembly code for
lambda forms.
Contributed-by: john.r.r...@oracle.com
Testing:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
One thing I noticed is that some methods I mentioned above
(List.subList(), Arrays.sort(), etc) throw
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/
It required some surgical work on tests to shove in the Arrays.asList test
case, since it is a
Hi Doug,
On 14/03/2014 9:42 PM, Doug Lea wrote:
On 03/14/2014 02:38 AM, Martin Buchholz wrote:
On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea d...@cs.oswego.edu
mailto:d...@cs.oswego.edu wrote:
On 03/13/2014 12:34 PM, Martin Buchholz wrote:
I notice there are zero jtreg tests for
On 14.03.2014 16:02, David Holmes wrote:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
One thing I noticed is that some methods I mentioned above
(List.subList(),
FYI, this change isn't limited to only bytecode assembly improvements,
but also contains caching of lambda forms for setters/getter of typed
arrays.
If there are any objections, I can back the caching logic out and
include it into one of upcoming changes.
Best regards,
Vladimir Ivanov
On
On 14/03/2014 10:14 PM, Ivan Gerasimov wrote:
On 14.03.2014 16:02, David Holmes wrote:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
One thing I noticed is that some
On 03/14/2014 08:07 AM, David Holmes wrote:
So what you are saying is that protected overrides of protected methods are not
required to honor the specification of the super method?
Not always, but ...
That certainly gives some implementation flexibility, but I don't think I've
ever seen it
On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
FYI, this change isn't limited to only bytecode assembly improvements, but
also contains caching of lambda forms for setters/getter of typed arrays.
Do you mean for MethodHandles.arrayElementGetter/Setter? If
Paul,
You are looking at the other fix (8037210).
The correct link is [1].
Best regards,
Vladimir Ivanov
[1]
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/src/share/classes/java/lang/invoke/MethodHandleImpl.java.sdiff.html
On 3/14/14 4:38 PM, Paul Sandoz wrote:
On Mar 14, 2014,
To get into this faster it would be nice if the new private fields (or the
existing ones for that matter) had a comment describing what they were for, e.g.
+ private final byte[] localTypes;
+ private final Class?[] localClasses;
I can figure it out from the code, but it would have been
On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
But in general it would be better to just use ThreadLocalRandom.current()
everywhere you use rnd variable. This is precisely it's purpose - a random
number generator that is never contended. The overhead of
ThreadLocalRandom.current() call
On Mar 14, 2014, at 3:42 AM, Peter Levart wrote:
This approach does have the advantage or not using volatile.
I've forgot to run this on my Raspberry Pi. Stay tuned...
I used to have a BeagleBoard on a previous project but do not have any of these
sorts of devices at my disposal at this
On 14/03/2014 12:04, Paul Sandoz wrote:
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037106-arrays.asList.forEach/webrev/
It required some surgical work on tests to shove in the
On 13/03/2014 23:07, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8035577/webrev/
New test case was added for
Adding serviceability-dev to the CC list as this seems to be where this
testlibrary has mostly been developed and maintained.
-Alan.
On 13/03/2014 14:02, Mattis Castegren wrote:
Hi
Could we have someone review this change. This is just a backport from JDK8,
but there were some small
On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Paul,
You are looking at the other fix (8037210).
The correct link is [1].
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the array
setter/getter
On Mar 14, 2014, at 4:46 PM, Martin Buchholz marti...@google.com wrote:
Looks good to me.
Thanks.
I'm willing to believe for-loop over array is as efficient as fortran-style
loop
+for (E e : a) {
+action.accept(e);
+}
Yeah, i previously
On 14.03.2014 18:18, Peter Levart wrote:
On 03/14/2014 01:14 PM, Ivan Gerasimov wrote:
On 14.03.2014 16:02, David Holmes wrote:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan
Hello!
This is a friendly reminder.
Can someone with the Reviewer status please help review this?
In short: we have a few java tests that run shell commands.
In some tests the path to the command is omitted, in other tests an
absolute path is given.
In the third group of tests, the *other*
On 3/14/2014 7:38 AM, Alan Bateman wrote:
On 13/03/2014 23:07, David Li wrote:
Hi,
This is an update from Xerces for file
impl/xpath/regex/TokenRange.java. For details, please refer to:
https://bugs.openjdk.java.net/browse/JDK-8035577.
Webrevs:
I may be wrong, but the test passes without the patch. It looks like we
may need to fix the bug David found:
https://bugs.openjdk.java.net/browse/JDK-8037324
-Joe
On 3/14/2014 10:01 AM, huizhe wang wrote:
On 3/14/2014 7:38 AM, Alan Bateman wrote:
On 13/03/2014 23:07, David Li wrote:
Hi,
Looks good to me. There are some additional optimization opportunities but they
can certainly wait.
Mike
On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
Looks good to me. There are some additional optimization opportunities but they
can certainly wait.
Mike
On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
Am 14.03.2014 17:10, schrieb Paul Sandoz:
I'm willing to believe for-loop over array is as efficient as fortran-style loop
+for (E e : a) {
+action.accept(e);
+}
Yeah, i previously went through a whole bunch of code replacing such
fortran-style loops
Yeah, the test passes without the patch. That is my error. The test I
wrote is for testing the correctness of the code I added. It doesn't
test the specific change. I can add another test for the change.
I can also move the bug I filed to this bug fix.
-David
On 3/14/2014 2:02 PM, huizhe
On Mar 14 2014, at 05:14 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
On 14.03.2014 16:02, David Holmes wrote:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
36 matches
Mail list logo
