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
looks fine.
On 5/5/15 2:53 PM, Joseph D. Darcy wrote:
Hello,
The regression test
test/java/util/regex/RegExTest.java
has been observed to intermittently fail. As the test uses randomness,
I'd like to update to the test to use the random number testing
library to better identify the caus
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
Hello,
The regression test
test/java/util/regex/RegExTest.java
has been observed to intermittently fail. As the test uses randomness,
I'd like to update to the test to use the random number testing library
to better identify the cause of any future failures.
Please review the patch belo
Looks fine Kumar; thanks,
-Joe
On 5/5/2015 1:37 PM, Kumar Srinivasan wrote:
Hello,
Please review the simple fix which allows the test to be run in its
own vm,
there seems to be some issue with the harness running in a concurrent
mode
specifically on Windows.
Thanks
Kumar
diff --git a/test
On 05/05/2015 01:33 PM, Mandy Chung wrote:
On 05/05/2015 02:04 AM, Yekaterina Kantserova wrote:
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8078896
webrev: http://cr.openjdk.java.net/~ykantser/8078896
com.sun.management has been moved to j
Hello,
Please review the simple fix which allows the test to be run in its own vm,
there seems to be some issue with the harness running in a concurrent mode
specifically on Windows.
Thanks
Kumar
diff --git a/test/tools/launcher/FXLauncherTest.java
b/test/tools/launcher/FXLauncherTest.java
--
On 05/05/2015 02:04 AM, Yekaterina Kantserova wrote:
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8078896
webrev: http://cr.openjdk.java.net/~ykantser/8078896
com.sun.management has been moved to jdk.management module. The patch
for JDK-8042
The changes seem reasonable those the comments in ValueBoxGen24 are somewhat
cryptic to me at least :-)
On May 5, 2015, at 12:30 PM, alexander stepanov
wrote:
> > _variableName in the public javadocs
>
> Please see
> http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/src/java.corba/share
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 again,
Here is a new webrev:
http://cr.openjdk.java.net/~shade/8076759/webrev.01/
Pruned the implementation details from expandCapacity Javadoc, and about
to submit a CCC for it.
Thanks,
-Aleksey.
On 05.05.2015 16:33, Roger Riggs wrote:
> Hi Aleksey,
>
> Thanks for checking the rounding a
I'd prefer to go the other way, deleting those trivial methods entirely,
utilizing the rarely used .new syntax.
Index: ConcurrentSkipListMap.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/Concurrent
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
> _variableName in the public javadocs
Please see
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/src/java.corba/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java.udiff.html
(please update the page as I didn't prepare a new webrev). Hopefully
that do not harm the code...
Tha
Hi Alexander,
Thank you, I guess I am not a fan of _variableName in the public javadocs as
it is not something we normally see.
Understand less is more, especially with CORBA.
On May 5, 2015, at 11:41 AM, alexander stepanov
wrote:
> Hello Lance,
>
> It just seemed to be less hazardous. E.
But yes, for 'writeValue' it could be renamed without any thoughts,
thanks...
On 05.05.2015 18:41, alexander stepanov wrote:
Hello Lance,
It just seemed to be less hazardous. E.g., method 'readValue' (in
ValueHandlerImpl) contains inner variable 'in' and parameter '_in'
being documented (als
Hello Lance,
It just seemed to be less hazardous. E.g., method 'readValue' (in
ValueHandlerImpl) contains inner variable 'in' and parameter '_in' being
documented (also, '_sender' - 'sender').
But of course the names could be swapped, if desired. I lazily preferred
not to touch the code (jus
Hi Alexander,
I just started to look at this and have a question:
/**
* Writes the value to the stream using java semantics.
- * @param out The stream to write the value to
+ * @param _out The stream to write the value to
* @param value The value to be written to the stream
Hello,
Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8079342/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8079342
Just some HTML markup fix for CORBA.
Thanks,
Alexander
Hi Dmitry, Staffan,
On 05/05/2015 12:38 PM, Staffan Larsen wrote:
Dmitry,
I think this should be reviewed on hotspot-gc and core-libs-dev as well
considering the changes to Finalizer.
I’m a little worried about the potentially very large String that is returned
from printFinalizationQueue().
Alan,
Thanks for the review! And for the catch - I'll fix it.
// Katja
On 05/05/2015 03:30 PM, Alan Bateman wrote:
Thanks Katja, this looks good. One thing that we should as part of
this is rev the requiredVersion in jdk/test/TEST.ROOT in case people
are using older versions of jtreg. I think
Hi Aleksey,
Thanks for checking the rounding alternative.
As for the CCC, since the implementation details are in the javadoc
then it will be needed either to remove the details or to update them.
I'd be inclined to try to remove them since they are there primarily for
performance.
Thanks, Ro
On 05/05/2015 10:04, Yekaterina Kantserova wrote:
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8078896
webrev: http://cr.openjdk.java.net/~ykantser/8078896
The push will be pushed to jdk9/dev.
Thanks Katja, this looks good. One thing that we shou
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/2015 05:12 AM, Paul Sandoz wrote:
On May 5, 2015, at 7:54 AM, Martin Buchholz wrote:
One query in ConcurrentSkipListMap, we have:
2500 // else use iterator
2501 @SuppressWarnings("unchecked") Iterator>
it =
2502 ((SubMap)m).entryIterator()
Dmitry,
I think this should be reviewed on hotspot-gc and core-libs-dev as well
considering the changes to Finalizer.
I’m a little worried about the potentially very large String that is returned
from printFinalizationQueue(). A possible different approach would be to write
printFinalizationQu
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
On 02/05/2015 09:27, Chris Hegarty wrote:
:
Thanks, this was an editing issue. Removed.
I think the javadoc looks quite good now, except may be the first
statement "Reads some bytes ...". It might be clearer to start with
"Reads a given number of bytes ...". The subsequent text makes the short
On May 5, 2015, at 7:54 AM, Martin Buchholz wrote:
>
> One query in ConcurrentSkipListMap, we have:
>
> 2500 // else use iterator
> 2501 @SuppressWarnings("unchecked") Iterator>
> it =
> 2502 ((SubMap)m).entryIterator();
>
> and then
>
> 2578
Hi,
Could I please have a review of this fix.
bug: https://bugs.openjdk.java.net/browse/JDK-8078896
webrev: http://cr.openjdk.java.net/~ykantser/8078896
The push will be pushed to jdk9/dev.
Thanks,
Katja
Alan's clarification from same change in hotspot (RFR: JDK-8075586: add
@modules as nee
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 Roger,
On 05/01/2015 08:19 PM, Roger Riggs wrote:
> Is there any additional benefit by rounding up the next multiple of 4 or 8.
> That would avoid a few wasted bytes at the end of the buffer modulo the
> allocation size.
It does not seem to help any further. Tried "plus32-round8", as in:
htt
Thanks for review, Ulf!
-Aleksey.
On 05/01/2015 05:29 PM, Ulf Zibis wrote:
> Hi Aleksey,
>
> I like this approach and to me the webrev looks good.
>
> -Ulf
>
>
> Am 24.04.2015 um 20:05 schrieb Aleksey Shipilev:
>> Hi,
>>
>> This seems to be a simple one-liner fix, but the background is more
>
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
On May 4, 2015, at 11:11 PM, Martin Buchholz wrote:
> Paul, thanks.
>
> Looks good.
>
> Test uses some impressive machinery, but I like what we did in jsr166 tck
> tests for similar sorts of tests:
> - rename latch to "done"
> - rename barrier to "threadsStarted"
> - rename "map" to "entry" o
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
38 matches
Mail list logo
