> On 31 Mar 2016, at 07:59, Ivan Gerasimov wrote:
>
>> I think they are important, more so the test update.
>>
>> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan
>> are you ok with that?
>>
>
> Sure!
>
Thanks.
> Here's the webrev, updated with those changes:
>
Looks good for me, thank you!
With best regards,
Tagir Valeev.
>> I think they are important, more so the test update.
>>
>> If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan
>> are you ok with that?
>>
IG> Sure!
IG> Here's the webrev, updated with those changes:
IG> h
I think they are important, more so the test update.
If we can roll ‘em to Ivan’s patch that would be the most efficient. Ivan are
you ok with that?
Sure!
Here's the webrev, updated with those changes:
http://cr.openjdk.java.net/~igerasim/8079136/10/webrev/
With kind regards,
Ivan
> On 30 Mar 2016, at 11:03, Tagir F. Valeev wrote:
>
> Hello!
>
> IG> After the fix for JDK-8148748 went in, I needed to rebase the fix.
> IG> Comparing to the previous webrev, the changes are local to
> IG> ArrayList.spliterator().
>
> IG> http://cr.openjdk.java.net/~igerasim/8079136/09/webre
Hello!
IG> After the fix for JDK-8148748 went in, I needed to rebase the fix.
IG> Comparing to the previous webrev, the changes are local to
IG> ArrayList.spliterator().
IG> http://cr.openjdk.java.net/~igerasim/8079136/09/webrev/
IG> The builds/tests are green.
Looks good to me, thanks.
By th
Hello!
After the fix for JDK-8148748 went in, I needed to rebase the fix.
Comparing to the previous webrev, the changes are local to
ArrayList.spliterator().
http://cr.openjdk.java.net/~igerasim/8079136/09/webrev/
The builds/tests are green.
With kind regards,
Ivan
On 03.02.2016 22:16, Iv
Hello everyone!
As the CCC request has been approved, the change is ready to be integrated.
Here's the latest variant of the webrev:
http://cr.openjdk.java.net/~igerasim/8079136/08/webrev/
It differs from the previous revision only in the javadoc section of
AbstractList.
All the code changes a
Hello!
Here's the updated webrev with rangeCheckForAdd() restored in both
AbstractList and ArrayList.
http://cr.openjdk.java.net/~igerasim/8079136/07/webrev/
The fix was built/tested successfully on all supported platforms.
Sincerely yours,
Ivan
On 02.02.2016 9:55, Martin Buchholz wrote:
On
On Mon, Feb 1, 2016 at 10:19 PM, Tagir F. Valeev wrote:
> I have a doubt about replacing rangeCheckForAdd. What if size() ==
> Integer.MAX_VALUE? This is not an issue for ArrayList as it's limited
> by MAX_ARRAY_SIZE which is Integer.MAX_VALUE - 8.
Actually, the limit is Integer.MAX_VALUE. But
Thanks Tagir for the comments!
On 02.02.2016 9:19, Tagir F. Valeev wrote:
Hello!
IG> It's misfortune that the spec of subList() doesn't match the spec of
IG> similar methods, like CharSequence.subSequence() or String.substring().
IG> It even contradicts the spec of List.subList(), which declar
Hello!
IG> It's misfortune that the spec of subList() doesn't match the spec of
IG> similar methods, like CharSequence.subSequence() or String.substring().
IG> It even contradicts the spec of List.subList(), which declares only IOOB
IG> to be thrown!
Yes, it's a pity. Isn't it the reason to chang
Thank you Tagir for the review!
On 29.01.2016 7:16, Tagir F. Valeev wrote:
Hello!
AbstractList::subListRangeCheck could be replaced with new
Objects::checkFromToIndex for consistency with other methods. Also
Yes, that would be good.
However, for AbstractList.subList() we have this in spec:
Hello!
AbstractList::subListRangeCheck could be replaced with new
Objects::checkFromToIndex for consistency with other methods. Also
AbstractList::rangeCheck could be replaced with Obejcts::checkIndex.
The same for ArrayList class.
Otherwise looks good to me.
With best regards,
Tagir Valeev.
IG
Hello everyone!
I'd like to respin the discussion.
The previous attempt can be found here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033159.html
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/05/webrev/
Here's th
Hi,
On 05/09/2015 04:36 PM, Ivan Gerasimov wrote:
On 09.05.2015 14:15, Doug Lea wrote:
On 05/08/2015 02:17 PM, Ivan Gerasimov wrote:
The spec says "The returned list is backed by this list"
and "The subclass's set(int, E), get(int), add(int, E), remove(int),
addAll(int, Collection) and remo
On 09.05.2015 14:15, Doug Lea wrote:
On 05/08/2015 02:17 PM, Ivan Gerasimov wrote:
The spec says "The returned list is backed by this list"
and "The subclass's set(int, E), get(int), add(int, E), remove(int),
addAll(int, Collection) and removeRange(int, int) methods all
delegate to the
corr
On 05/08/2015 02:17 PM, Ivan Gerasimov wrote:
The spec says "The returned list is backed by this list"
and "The subclass's set(int, E), get(int), add(int, E), remove(int),
addAll(int, Collection) and removeRange(int, int) methods all delegate to the
corresponding methods on the backing abstract
Thank you Doug for your comments!
On 08.05.2015 20:10, Doug Lea wrote:
On 05/08/2015 10:49 AM, Ivan Gerasimov wrote:
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
I think that the propos
On 05/08/2015 10:49 AM, Ivan Gerasimov wrote:
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
I think that the proposed fix formally conforms to the spec.
That would surprise me. The spec say
On 08.05.2015 1:26, Martin Buchholz wrote:
On Thu, May 7, 2015 at 12:23 PM, Doug Lea wrote:
It would be possible (and easy) to create a specialization for the
java.util.Arrays.ArrayList class (i.e., the kind returned by
Arrays.asList(a).subList), which would also fix the SOE problem
in this p
Hi Doug!
On 07.05.2015 22:23, Doug Lea wrote:
On 05/06/2015 07:23 PM, Martin Buchholz wrote:
Hi Ivan,
I'm afraid of these changes - they are hard to review.
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#sub
On Thu, May 7, 2015 at 3:07 PM, Martin Buchholz wrote:
>
>>> if ((fromIndex < 0) | (toIndex > size) | (fromIndex > toIndex))
>>> slowpath();
>>>
>>>
Yeah, the refined proposal would be
if ((fromIndex | (size - toIndex) | (toIndex - fromIndex)) < 0) slowpath();
considering that here performance
On Thu, May 7, 2015 at 12:23 PM, Doug Lea wrote:
>
> It would be possible (and easy) to create a specialization for the
> java.util.Arrays.ArrayList class (i.e., the kind returned by
> Arrays.asList(a).subList), which would also fix the SOE problem
> in this particular case.
It seems it would be
On Thu, May 7, 2015 at 9:18 AM, Ivan Gerasimov
wrote:
>
> ---
>>
>> I would make modCount an argument to updateSizeAndModCount.
>>
>> I did that initially, but later realized that this argument should never
> be different from root.modCount.
>
>
Sure, but you'd keep it in a local variable in th
Hi Doug,
> The reason that flattened forms were not used is that each
> layer does not in general know the class of its parent.
Could you please explain this a bit more? I'm afraid I don't quite understand
how this is possible. Thanks.
-Pavel
On 05/06/2015 07:23 PM, Martin Buchholz wrote:
Hi Ivan,
I'm afraid of these changes - they are hard to review.
I believe that they also break the AbstractList.subList spec.
http://docs.oracle.com/javase/8/docs/api/java/util/AbstractList.html#subList-int-int-
The reason that flattened forms w
Hi Martin!
I'm afraid of these changes - they are hard to review.
Can't we fix the SOE with a relatively small change to
ArrayList.SubList methods that recursively invoke parent methods to
use iteration instead, i.e. can't you implement updateSizeAndModCount
in the existing SubList class?
On May 7, 2015, at 1:23 AM, Martin Buchholz wrote:
> Hi Ivan,
>
> I'm afraid of these changes - they are hard to review.
>
> Can't we fix the SOE with a relatively small change to ArrayList.SubList
> methods that recursively invoke parent methods to use iteration instead,
Since all that woul
Hi Ivan,
I'm afraid of these changes - they are hard to review.
Can't we fix the SOE with a relatively small change to ArrayList.SubList
methods that recursively invoke parent methods to use iteration instead,
i.e. can't you implement updateSizeAndModCount in the existing SubList
class?
---
I w
And here's another update:
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/2/webrev/
This is cleaner.
For extra bonus test points you could add singleton-list, checked wrappers, and
synchronized list wrappers to the test set.
Done.
I also added a simple implementation of AbstractList,
On 06/05/15 16:47, Paul Sandoz wrote:
n May 6, 2015, at 4:08 PM, Ivan Gerasimov wrote:
>Hello everyone!
>
>Here's the second iteration of the fix.
>
>BUGURL:https://bugs.openjdk.java.net/browse/JDK-8079136
>WEBREV:http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
>
This is cleaner.
For
On May 6, 2015, at 4:08 PM, Ivan Gerasimov wrote:
> Hello everyone!
>
> Here's the second iteration of the fix.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
> WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
>
This is cleaner.
For extra bonus test points you co
Hi Pavel!
It was intentional to avoid checking for co-modification for every pair
of list-sublist in the chain.
It's surely enough to only compare modCount of the root and the sublist
we're dealing with.
However, I didn't notice that SubList.size() had not checked for
comodifications recursi
Hello everyone!
Here's the second iteration of the fix.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8079136
WEBREV: http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/
I changed all the sub-list classes to be non internal, but standalone.
I think the logic become more obvious now.
Arra
Ivan,
It looks like your change (I don't know whether it was intentional or not)
brings some more "fail-fast"-ness which is good! For instance, before the
change, this snippet:
List integers = new LinkedList<>();
integers.addAll(Arrays.asList(0, 1));
List sublist = integers.subList(0
The problem of deep nesting of sublists was known to previous generations
of ArrayList maintainers.
We got discouraged because there is no known way to make operations that
are O(1) on the full list also O(1) on subsub...sublists. It's especially
a performance problem when you use ArrayLists with
Thanks Louis for looking at this!
Removing an element from a sub-sublist is done as:
549 public E remove(int index) {
550 rangeCheck(index);
551 checkForComodification();
552 E result = AbstractList.this.remove(index + offset);
553 upda
Just checking -- IIRC, this will change the semantics of how structural
modifications to a subList of a subList will affect the first subList. For
example, I believe in the past, removing an element from a subList of a
subList would decrease the size of the first subList by 1, but now the
first su
Hi Paul
On 05.05.2015 19:56, Paul Sandoz wrote:
Hi Ivan,
ArrayList
--
You can simplify SubList with:
private final class SubList extends AbstractList implements RandomAccess {
private final SubList parent;
private final int offset;
int size;
// Top level sub-list
Sub
Hi Ivan,
ArrayList
--
You can simplify SubList with:
private final class SubList extends AbstractList implements RandomAccess {
private final SubList parent;
private final int offset;
int size;
// Top level sub-list
SubList(int offset, int fromIndex, int toIndex) {
t
Hi Ivan,
On 05/05/15 14:55, Ivan Gerasimov wrote:
I converted the SubList into an inner class to make the implementations
for AbstractList.SubList and ArrayList.SubList similar.
It might be not worth doing so, but I thought it would be easier to
maintain those classes, if they have similar struc
On 05.05.2015 13:23, Daniel Fuchs wrote:
On 05/05/15 10:58, Ivan Gerasimov wrote:
Thank you Daniel for taking look at it!
On 05.05.2015 11:14, Daniel Fuchs wrote:
Hi Ivan,
Have you considered to simply override/change subList(int fromIndex,
int toIndex)
in SubList and RandomAccessSubList -
On 05/05/15 10:58, Ivan Gerasimov wrote:
Thank you Daniel for taking look at it!
On 05.05.2015 11:14, Daniel Fuchs wrote:
Hi Ivan,
Have you considered to simply override/change subList(int fromIndex,
int toIndex)
in SubList and RandomAccessSubList - so that 'l'/'parent' points
always to the or
Thank you Daniel for taking look at it!
On 05.05.2015 11:14, Daniel Fuchs wrote:
Hi Ivan,
Have you considered to simply override/change subList(int fromIndex,
int toIndex)
in SubList and RandomAccessSubList - so that 'l'/'parent' points
always to the original
root list (instead of being a su
Hi Ivan,
Have you considered to simply override/change subList(int fromIndex, int
toIndex)
in SubList and RandomAccessSubList - so that 'l'/'parent' points always
to the original
root list (instead of being a sublist of sublist of sublist)?
It seems to me that overriding sublist to create a s
Hello!
When creating a sublist with List.subList(), it keeps a reference to its
parent.
Then, when accessing (get(), set(), add(), remove(), etc.) the sublist,
it recursively calls the corresponding methods of its parent.
This recursion, when deep enough, can cause StackOverflowError.
The onl
46 matches
Mail list logo
