On Mar 14 2014, at 05:14 , 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:
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
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 wi
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 wrote:
> Hi,
>
> This patch overrides some default methods with more optimal ones for the
> Arrays.asList implementation:
>
>
> http://cr.openjdk
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 wrote:
> Hi,
>
> This patch overrides some default methods with more optimal ones for the
> Arrays.asList implementation:
>
>
> http://cr.openjdk
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,
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: http://cr.openjdk.java.net/~joehw/jdk9/80355
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* abso
Doh! crossed webrevs, thanks.
Just had a quick look, this looks like a really nice improvement to the array
setter/getter support, definitely simplified. IIUC the mh.viewAsType will now handle the
appropriate casting. I believe it might reduce the "ceremony" for array
setter/getter MHs [1].
I
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 Gerasimov
On Mar 14, 2014, at 4:46 PM, Martin Buchholz 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 went through
On Mar 14, 2014, at 2:17 PM, Vladimir Ivanov
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 support, definitely simplified.
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 change
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 code
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 Arr
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 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 Gerasimov wrote:
One thing I noticed is that some m
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(
Hi Jochen,
On 2014-03-10, Jochen Theodorou wrote:
>
> You basically find this sentence for Class#getInterfaces() and
> Class#getGenericInterfaces() "If this object represents a class, the
> return value is an array containing objects representing all
> interfaces implemented by the class."
>
> T
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 a
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, at
On Mar 14, 2014, at 1:19 PM, Vladimir Ivanov
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 so i don't see
relevant
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 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 m
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 3/
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(), Array
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 mailto:d...@cs.oswego.edu>> wrote:
On 03/13/2014 12:34 PM, Martin Buchholz wrote:
I notice there are zero jtreg tests for removeRange. That
shoul
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 factor
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 IllegalArgumentExcepti
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: jdk/java/{la
On 03/14/2014 02:38 AM, Martin Buchholz wrote:
On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea mailto:d...@cs.oswego.edu>> wrote:
On 03/13/2014 12:34 PM, Martin Buchholz wrote:
I notice there are zero jtreg tests for removeRange. That should be
fixed.
I notice there is a removeRa
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: john.r.r...@orac
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 IndexOutOfBoundExce
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, Ivan
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?
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 an
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 (
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 cou
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 CCC
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 before,
40 matches
Mail list logo
