Re: RFR: jsr166 jdk integration 2018-05

I agree with "tempest in a teapot". The practical effect either way will be small. We seem unlikely to convince each other with new arguments. My thinking may be influenced by my growing belief that having ConcurrentModificationException in the core libraries at all was a mistake - they belong i

Re: RFR: jsr166 jdk integration 2018-05

On 5/22/18 2:58 PM, Stuart Marks wrote: On 5/22/18 8:50 AM, Martin Buchholz wrote: We seem to have enough consensus to change the modCount behavior of replaceAll. Sorry, I don't agree that there is such consensus. There are about half a dozen different issues all at play, spread across sev

Re: RFR: jsr166 jdk integration 2018-05

On 23/05/2018 4:40 PM, Martin Buchholz wrote: On Tue, May 22, 2018 at 3:41 PM, joe darcy wrote: The specification of CME is not sacrosanct. We can and do evolve the specification of types all the time, even ones that have been in the platform for many years. We certainly have constraints on t

Re: RFR: jsr166 jdk integration 2018-05

On Tue, May 22, 2018 at 3:41 PM, joe darcy wrote: > > The specification of CME is not sacrosanct. We can and do evolve the > specification of types all the time, even ones that have been in the > platform for many years. We certainly have constraints on that evolution > to maintain compatibility

Re: RFR: jsr166 jdk integration 2018-05

Hi John, On 5/19/2018 3:54 PM, John Rose wrote: On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: I like thinking of ArrayList as just an optimized HashMap, Lua-style, and HashMap.replaceAll also does not increment modCount, supporting our "structural modification" position. The thing that

Re: RFR: jsr166 jdk integration 2018-05

Hi Martin, On 5/22/18 8:50 AM, Martin Buchholz wrote: We seem to have enough consensus to change the modCount behavior of replaceAll. Sorry, I don't agree that there is such consensus. There are about half a dozen different issues all at play, spread across several messages throughout the th

Re: RFR: jsr166 jdk integration 2018-05

We seem to have enough consensus to change the modCount behavior of replaceAll. But let's leave that to a future change and get this integration in by (temporarily) reverting to the status quo: Index: src/main/java/util/ArrayList.java ===

Re: RFR: jsr166 jdk integration 2018-05

Hi John, On 20/05/2018 8:54 AM, John Rose wrote: On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: I like thinking of ArrayList as just an optimized HashMap, Lua-style, and HashMap.replaceAll also does not increment modCount, supporting our "structural modification" position. The thing tha

Re: RFR: jsr166 jdk integration 2018-05

On 05/20/18 00:54, John Rose wrote: The phrase “incorrect results” in List cannot be carte blanche to add checks where we are afraid the programmer might have made an error even if we cannot prove one; that would be just officious mind-reading. +1 I'm all for adding checks that prevent progra

Re: RFR: jsr166 jdk integration 2018-05

On May 19, 2018, at 9:42 AM, Martin Buchholz wrote: > > I like thinking of ArrayList as just an optimized HashMap, Lua-style, and > HashMap.replaceAll also does not increment modCount, supporting our > "structural modification" position. > > The thing that bothers me most about the status quo is

Re: RFR: jsr166 jdk integration 2018-05

I like thinking of ArrayList as just an optimized HashMap, Lua-style, and HashMap.replaceAll also does not increment modCount, supporting our "structural modification" position. The thing that bothers me most about the status quo is the *inconsistency* - between root list and subList, between defa

Re: RFR: jsr166 jdk integration 2018-05

On Fri, May 18, 2018 at 4:30 PM, joe darcy wrote: > Hello, > > On 5/17/2018 8:51 PM, Stuart Marks wrote: > >> >> Given that the replaceAll methods have incremented modCount since they > were introduced in JDK 8, changing that behavior in widely-used classes > merits a CSR to be filed for JDK 11.

Re: RFR: jsr166 jdk integration 2018-05

Sorry Paul but all this does is endorse the second camp: they want structural and content modifications to trigger CME. Further it assumes that doing a replaceAll while an iterator is active is always an error which need not be the case. CME is about the safety of the implementation, not the se

Re: RFR: jsr166 jdk integration 2018-05

Hello, On 5/17/2018 8:51 PM, Stuart Marks wrote: I owe all of you replies on this, but I don't have time to continue the discussion, and I suspect you all want to get on with things. Let me have a quick chat with Paul tomorrow and then I'll propose a path forward. I've spoken about this p

Re: RFR: jsr166 jdk integration 2018-05

Hi, My CME budget is definitely in the red now :-) but i would like to attempt to summarize the different positions and suggest a solution. If that does not get traction i believe a graceful retreat is in order. We appear to be in two different philosophical camps with regards to the interpr

Re: RFR: jsr166 jdk integration 2018-05

I owe all of you replies on this, but I don't have time to continue the discussion, and I suspect you all want to get on with things. Let me have a quick chat with Paul tomorrow and then I'll propose a path forward. s'marks

Re: RFR: jsr166 jdk integration 2018-05

Sorry Stuart, but I'm joining the no-modCount barrage. To pick on the main issue... On 05/16/2018 05:21 PM, Stuart Marks wrote: > Suppose that a replaceAll() on another thread occurs, and that this is > allowed. Does the application care whether the eventual printout > contains partly new values

Re: RFR: jsr166 jdk integration 2018-05

On 17/05/2018 4:25 AM, Stuart Marks wrote: On 5/15/18 7:37 PM, David Holmes wrote: I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the pr

Re: RFR: jsr166 jdk integration 2018-05

On Wed, May 16, 2018 at 2:21 PM, Stuart Marks wrote: > > > On 5/15/18 8:02 PM, Martin Buchholz wrote: > >> >> How many times the lock is acquired is an implementation detail, a >> non-obvious tradeoff even. >> vector.replaceAll holds the lock throughout, but vector.subList(0, >> size).replaceAll

Re: RFR: jsr166 jdk integration 2018-05

On 5/15/18 8:02 PM, Martin Buchholz wrote: How many times the lock is acquired is an implementation detail, a non-obvious tradeoff even. vector.replaceAll holds the lock throughout, but vector.subList(0, size).replaceAll holds the lock for each element (sigh ... racily (really a bug!)). In

Re: RFR: jsr166 jdk integration 2018-05

On Wed, May 16, 2018 at 11:25 AM, Stuart Marks wrote: > > > On 5/15/18 7:37 PM, David Holmes wrote: > >> I'm still with Martin on this. It makes no sense to me to allow replacing >> one element to not cause CME, but replacing more than one does cause CME. >> This is inconsistent and confusing and

Re: RFR: jsr166 jdk integration 2018-05

On 5/15/18 7:37 PM, David Holmes wrote: I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the programmer won't know what to expect when or

Re: RFR: jsr166 jdk integration 2018-05

On Tue, May 15, 2018 at 5:34 PM, Stuart Marks wrote: > >> > Bringing replaceAll() to the public API exposes it as a single operation, > with its own semantics. > Note that Vector.replaceAll() holds the lock for the entire operation, not > merely around individual set() operations. It really

Re: RFR: jsr166 jdk integration 2018-05

I'm still with Martin on this. It makes no sense to me to allow replacing one element to not cause CME, but replacing more than one does cause CME. This is inconsistent and confusing and the end result is the programmer won't know what to expect when or why. The original intent of CME, from my

Re: RFR: jsr166 jdk integration 2018-05

(TL;DR - replaceAll incrementing modCount is a bug.) I acknowledge that statement is the one in dispute. Hmmm ... my previous convincing arguments have failed to convince ?! Your argument above applies to List.set just as much as List.repladeAll, because the latter is nothing more semantical

Re: RFR: jsr166 jdk integration 2018-05

On Tue, May 15, 2018 at 11:35 AM, Martin Buchholz wrote: > > Your argument above applies to List.set just as much as List.repladeAll, > because the latter is nothing more semantically than a bunch of calls to > the former. They should have the same behavior. Not having the same > behavior leads

Re: RFR: jsr166 jdk integration 2018-05

On Tue, May 15, 2018 at 10:19 AM, Stuart Marks wrote: > > > I mentally revised the history when doing the collections/stream API work >> since we added more bulk operations, since this is on a “best effort” >> basis >> and if it’s cheap to do then there is no real harm in it and it m

Re: RFR: jsr166 jdk integration 2018-05

I mentally revised the history when doing the collections/stream API work since we added more bulk operations, since this is on a “best effort” basis and if it’s cheap to do then there is no real harm in it and it might help. Spec says: """protected transient int modCount The number of tim

Re: RFR: jsr166 jdk integration 2018-05

> On May 14, 2018, at 5:51 PM, David Holmes wrote: > > On 15/05/2018 7:56 AM, Paul Sandoz wrote: >>> On May 14, 2018, at 2:04 PM, Martin Buchholz wrote: >>> On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz >> > wrote: On May 14, 2018, at 12:43 PM, Martin Buchhol

Re: RFR: jsr166 jdk integration 2018-05

On 15/05/2018 7:56 AM, Paul Sandoz wrote: On May 14, 2018, at 2:04 PM, Martin Buchholz wrote: On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz mailto:paul.san...@oracle.com>> wrote: On May 14, 2018, at 12:43 PM, Martin Buchholz mailto:marti...@google.com>> wrote: On Mon, May 14, 2018 at 12:18 PM, P

Re: RFR: jsr166 jdk integration 2018-05

> On May 14, 2018, at 2:04 PM, Martin Buchholz wrote: > > > > On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz > wrote: > > >> On May 14, 2018, at 12:43 PM, Martin Buchholz > > wrote: >> >> >> >> On Mon, May 14, 2018 at 12:18 PM, Pa

Re: RFR: jsr166 jdk integration 2018-05

On Mon, May 14, 2018 at 1:45 PM, Paul Sandoz wrote: > > > On May 14, 2018, at 12:43 PM, Martin Buchholz wrote: > > > > On Mon, May 14, 2018 at 12:18 PM, Paul Sandoz > wrote: > >> >>> A CME is not necessarily associated with just structural modifications >>> it could, on a best effort basis, be

Re: RFR: jsr166 jdk integration 2018-05

> On May 14, 2018, at 12:43 PM, Martin Buchholz wrote: > > > > On Mon, May 14, 2018 at 12:18 PM, Paul Sandoz > wrote: >> >> A CME is not necessarily associated with just structural modifications it >> could, on a best effort basis, be associated with any modi

Re: RFR: jsr166 jdk integration 2018-05

On Mon, May 14, 2018 at 12:18 PM, Paul Sandoz wrote: > >> A CME is not necessarily associated with just structural modifications it >> could, on a best effort basis, be associated with any modification, which >> is cheaper to do for bulk operations rather than individual operations, and >> this o

Re: RFR: jsr166 jdk integration 2018-05

> On May 11, 2018, at 9:33 AM, Martin Buchholz wrote: > > > > On Fri, May 11, 2018 at 9:06 AM, Paul Sandoz > wrote: > > >> On May 9, 2018, at 11:17 AM, Martin Buchholz > > wrote: >> >> Time to do this, since Claes is also touching

Re: RFR: jsr166 jdk integration 2018-05

On Fri, May 11, 2018 at 9:06 AM, Paul Sandoz wrote: > > > On May 9, 2018, at 11:17 AM, Martin Buchholz wrote: > > Time to do this, since Claes is also touching ArrayList. > > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166- > integration/overview.html > > 8202685: Improve ArrayList replace

Re: RFR: jsr166 jdk integration 2018-05

> On May 9, 2018, at 11:17 AM, Martin Buchholz wrote: > > Time to do this, since Claes is also touching ArrayList. > > http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > > > 82

Re: RFR: jsr166 jdk integration 2018-05

On 2018-05-09 20:17, Martin Buchholz wrote: 8202685: Improve ArrayList replaceAll http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAll/index.html https://bugs.openjdk.java.net/b