core-libs-dev

Download

core-libs-dev@openjdk.org

August 2018

82 participants
102 discussions

RFR(XXS) : 8208647 : switch jtreg to 4.2b13
by Igor Ignatyev 02 Aug '18

02 Aug '18

http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html > 5 lines changed: 0 ins; 0 del; 5 mod; Hi all, could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated. webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 testing: tier1-2 Thanks, -- Igor

4 5

RE: core-libs-dev Digest, Vol 135, Issue 86
by Baesken, Matthias 01 Aug '18

01 Aug '18

Hi Brian , I'll build it on AIX + in case it builds fine put it into our test patch queue . Best regards , Matthias > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 Jul 2018 11:47:57 -0700 > From: Brian Burkhalter <brian.burkhalter(a)oracle.com> > To: "B. Blaser" <bsrbnd(a)gmail.com> > Cc: core-libs-dev <core-libs-dev(a)openjdk.java.net> > Subject: [PING] Re: [12] (AIX) 8207744: Clean up inconsistent use of > opendir/closedir versus opendir64/closedir64 > Message-ID: <944A18E9-D6E3-494D-9C94-875845507E33(a)oracle.com> > Content-Type: text/plain; charset=us-ascii > > Hi, > > Does anyone have any further comments on this? > > Is there anyone willing to volunteer to build and test it on AIX? > > Thanks, > > Brian > > On Jul 30, 2018, at 1:35 PM, Brian Burkhalter <brian.burkhalter(a)oracle.com> > wrote: > > > Hi Bernard, > > > > Yes we agree. I believe I already had that change to those two files in the > revised (.01) version of the patch which I posted on Friday: > > > > http://cr.openjdk.java.net/~bpb/8207744/webrev.01/index.html > > > > Thanks, > > > > Brian > > > > On Jul 28, 2018, at 7:10 AM, B. Blaser <bsrbnd(a)gmail.com> wrote: > > > >> In these files, only 'TimeZone_md.c' & 'OperatingSystemImpl.c' seem to > >> be missing '#define opendir opendir64' (etc...) for AIX. > >> > >> So, I guess I would do (blindly) something more like the patch below. > >> > >> Do we agree? > > > > ------------------------------ > > Message: 2 > Date: Tue, 31 Jul 2018 19:08:45 +0000 > From: Alex Foster <alexfoster(a)hotmail.ca> > To: Stuart Marks <stuart.marks(a)oracle.com> > Cc: "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net> > Subject: Re: 8143850: retrofit ArrayDeque to implement List > Message-ID: > <DM5PR1601MB113260B3D990190B725D1D54A52E0@DM5PR1601MB > 1132.namprd16.prod.outlook.com> > > Content-Type: text/plain; charset="iso-8859-1" > > Sure, I don't mind. I would have done that myself but I don't think I have > access to upload to cr.openjdk.java.net. > > > Alex > > ________________________________ > From: Stuart Marks <stuart.marks(a)oracle.com> > Sent: July 31, 2018 2:40 PM > To: Alex Foster > Cc: core-libs-dev(a)openjdk.java.net > Subject: Re: 8143850: retrofit ArrayDeque to implement List > > > OK, great. > > > It looks like a heavily modified version of ArrayDeque.java. This makes it a bit > difficult to understand what the changes are. Would you mind if I rehosted > this to cr.openjdk.java.net and generated a webrev for it? > > > Thanks, > > > s'marks > > On 7/28/18 11:05 PM, Alex Foster wrote: > > Hi, > > > Here's my current proposal: https://pastebin.com/EABgwLYS > > > Alex > > > ________________________________ > From: Stuart Marks > <stuart.marks(a)oracle.com><mailto:stuart.marks@oracle.com> > Sent: July 28, 2018 8:11 PM > To: Martin Buchholz; Alex Foster > Cc: Doug Lea; core-libs-dev(a)openjdk.java.net<mailto:core-libs- > dev(a)openjdk.java.net> > Subject: Re: 8143850: retrofit ArrayDeque to implement List > > Hi, I finally got some time to get my head around this. > > Conceptually, I like the idea of a List that's stored in a circular array, like > ArrayDeque. The best way to manifest this in the API isn't obvious though. I > filed the bug as "retrofit ArrayDeque to implement List" but of course it > doesn't have to be this way. > > I also think we want to reuse an existing implementation as much as possible. > There's already too much duplication between ArrayList and ArrayDeque; we > don't > want a third similar implementation that will need to be maintained in > parallel. > > To Martin's points: > > * Adding List-like methods to ArrayDeque without it implementing List is > indeed > odd, but not necessarily fatal. It does seem to raise the question "Isn't there > a better way?" though. > > * I don't want to have to add null support if at all possible, for the reasons > Martin mentioned. Also, it's an implementation and maintenance headache. > Of > course the implementations like ArrayList and HashMap are proof that it can > be > done. But each time HashMap has been enhanced significantly, there's been > a bug > tail where null checking was missed in certain cases. > > * Growth policy. The shared null array setup for ArrayList was added when > we > observed that a significant number of ArrayLists are created with the default > constructor and then never populated. Allocating the backing array lazily > resulted in a considerable space savings. I think this would be a good idea to > do for ArrayDeque, but this is somewhat orthogonal to the current "retrofit > List" discussion. > > * Regarding nestmates, I don't think the use of nestmates has any advantage > or > disadvantage over package-level access between top-level classes in the > same > package. I think we should decide what we want the API to look like first, and > then figure out how to factor things so that we can get the code sharing and > coupling that we want. We might not be forced into contorting the API in > order > to get better sharing/coupling, but let's wait to cross that bridge if we come > to it. > > -- > > Alex, I'm not sure where your current proposal stands. Have you sent an > update > since the head of the thread? If you had included something as an > attachment, it > has likely been stripped. > > Thanks, > > s'marks > > > > > > On 7/23/18 8:46 PM, Martin Buchholz wrote: > > (As usual, I don't have enough time to devote to this at the moment) > > > > I sort of like the idea of adding all of those List methods to ArrayDeque, but > > it's __weird__ for java code to do that, and remove(int) is a problem when > you > > have ArrayDeque<Integer>, so it will probably end up rejected. > > > > --- > > > > Similarly, the idea of an ArrayDeque subclass that accepts nulls will be > > unpopular - null elements have fallen out of favor. > > > > While|Deque|implementations are not strictly required to prohibit the > insertion > > of null elements, they are strongly encouraged to do so. Users of > > any|Deque|implementations that do allow null elements are strongly > > encouraged/not/to take advantage of the ability to insert nulls. This is so > > because|null|is used as a special return value by various methods to > indicate > > that the deque is empty. > > > > --- > > > > It makes some sense for ArrayDeque's growth policy to be very similar to > > ArrayList's - that should be done as an independent change. Are there any > > lessons to be learned from ArrayList's experience? Is the world filled with > > empty ArrayDeques that could share a common backing array? > > > > --- > > > > I do like the idea of having ArrayDeque's List-implementing subclass be a > > nestmate of ArrayDeque, to share implementation details and to help > discovery > > and naming. I'm not thrilled with reusing "List" in ArrayDeque.List but I > don't > > have a great alternative to suggest. > > > > > > On Mon, Jul 16, 2018 at 10:36 AM, Alex Foster > <alexfoster(a)hotmail.ca<mailto:alexfoster@hotmail.ca> > > <mailto:alexfoster@hotmail.ca>> wrote: > > > > Hi again, > > > > I updated ArrayDeque with your last idea (adding all list methods but not > > implementing List) and added a subclass ArrayDeque.List which overrides > > equals and hashcode and implements List. There is also a subclass > > ArrayDeque.WithNulls that accepts null elements. ArrayDeque has > removeAt(int > > index) instead of remove(index) to avoid overloading remove(Object). > > > > I also added shared empty arrays similar to Arraylist, and a reallocate > > method which can do the same things as trimToSize and ensure capacity > in > > Arraylist. It also allows you to trim to a specific capacity other than the > > size or skip trimming if the capacity is within a specified distance of the > > target capacity. > > > > Also the bulk add methods call collection.toArray, then check the array > for > > illegal elements, then add the array, which means that a collection could > > keep the array it returns from toArray and modify it from another thread > > after it has been checked but before it has been added which could lead > to > > illegal elements being added to the ArrayDeque. We could maybe avoid > this by > > cloning the array or checking the elements after adding them but I'm not > > sure if it's worth it... > > > > What do you think? > > > > I also changed the WhiteBox test a bit: > > > > --- a/test/jdk/java/util/ArrayDeque/WhiteBox.java > > +++ b/test/jdk/java/util/ArrayDeque/WhiteBox.java > > @@ -88,7 +88,10 @@ > > > > @Test > > public void defaultConstructor() { > > - checkCapacity(new ArrayDeque(), 16); > > + ArrayDeque d = new ArrayDeque(); > > + d.add(new Object()); > > + d.clear(); > > + checkCapacity(d, 16); > > } > > > > @Test > > @@ -131,7 +134,7 @@ > > if (rnd.nextBoolean()) d.add(99); > > ArrayDeque clone = serialClone(d); > > assertInvariants(clone); > > - assertNotSame(elements(d), elements(clone)); > > + assertTrue(d.isEmpty() || elements(d) != elements(clone)); > > assertEquals(d, clone); > > } > > } > > > > Alex > > > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 31 Jul 2018 21:10:53 +0200 > From: Patrick Reinhart <patrick(a)reini.net> > To: Alex Foster <alexfoster(a)hotmail.ca>, Stuart Marks > <stuart.marks(a)oracle.com> > Cc: "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net> > Subject: Re: 8143850: retrofit ArrayDeque to implement List > Message-ID: <e126a760-de69-e91f-aa21-d44c30bc81e0(a)reini.net> > Content-Type: text/plain; charset=utf-8 > > Hi Alex, > > I can do that for you .... > > -Patrick > > Am 31.07.2018 um 21:08 schrieb Alex Foster: > > Sure, I don't mind. I would have done that myself but I don't think I have > access to upload to cr.openjdk.java.net. > > > > > > Alex > > > > ________________________________ > > From: Stuart Marks <stuart.marks(a)oracle.com> > > Sent: July 31, 2018 2:40 PM > > To: Alex Foster > > Cc: core-libs-dev(a)openjdk.java.net > > Subject: Re: 8143850: retrofit ArrayDeque to implement List > > > > > > OK, great. > > > > > > It looks like a heavily modified version of ArrayDeque.java. This makes it a > bit difficult to understand what the changes are. Would you mind if I > rehosted this to cr.openjdk.java.net and generated a webrev for it? > > > > > > Thanks, > > > > > > s'marks > > > > On 7/28/18 11:05 PM, Alex Foster wrote: > > > > Hi, > > > > > > Here's my current proposal: https://pastebin.com/EABgwLYS > > > > > > Alex > > > > > > ________________________________ > > From: Stuart Marks > <stuart.marks(a)oracle.com><mailto:stuart.marks@oracle.com> > > Sent: July 28, 2018 8:11 PM > > To: Martin Buchholz; Alex Foster > > Cc: Doug Lea; core-libs-dev(a)openjdk.java.net<mailto:core-libs- > dev(a)openjdk.java.net> > > Subject: Re: 8143850: retrofit ArrayDeque to implement List > > > > Hi, I finally got some time to get my head around this. > > > > Conceptually, I like the idea of a List that's stored in a circular array, like > > ArrayDeque. The best way to manifest this in the API isn't obvious though. I > > filed the bug as "retrofit ArrayDeque to implement List" but of course it > > doesn't have to be this way. > > > > I also think we want to reuse an existing implementation as much as > possible. > > There's already too much duplication between ArrayList and ArrayDeque; > we don't > > want a third similar implementation that will need to be maintained in > parallel. > > > > To Martin's points: > > > > * Adding List-like methods to ArrayDeque without it implementing List is > indeed > > odd, but not necessarily fatal. It does seem to raise the question "Isn't > there > > a better way?" though. > > > > * I don't want to have to add null support if at all possible, for the reasons > > Martin mentioned. Also, it's an implementation and maintenance > headache. Of > > course the implementations like ArrayList and HashMap are proof that it > can be > > done. But each time HashMap has been enhanced significantly, there's > been a bug > > tail where null checking was missed in certain cases. > > > > * Growth policy. The shared null array setup for ArrayList was added when > we > > observed that a significant number of ArrayLists are created with the > default > > constructor and then never populated. Allocating the backing array lazily > > resulted in a considerable space savings. I think this would be a good idea > to > > do for ArrayDeque, but this is somewhat orthogonal to the current "retrofit > > List" discussion. > > > > * Regarding nestmates, I don't think the use of nestmates has any > advantage or > > disadvantage over package-level access between top-level classes in the > same > > package. I think we should decide what we want the API to look like first, > and > > then figure out how to factor things so that we can get the code sharing > and > > coupling that we want. We might not be forced into contorting the API in > order > > to get better sharing/coupling, but let's wait to cross that bridge if we come > > to it. > > > > -- > > > > Alex, I'm not sure where your current proposal stands. Have you sent an > update > > since the head of the thread? If you had included something as an > attachment, it > > has likely been stripped. > > > > Thanks, > > > > s'marks > > > > > > > > > > > > On 7/23/18 8:46 PM, Martin Buchholz wrote: > >> (As usual, I don't have enough time to devote to this at the moment) > >> > >> I sort of like the idea of adding all of those List methods to ArrayDeque, > but > >> it's __weird__ for java code to do that, and remove(int) is a problem > when you > >> have ArrayDeque<Integer>, so it will probably end up rejected. > >> > >> --- > >> > >> Similarly, the idea of an ArrayDeque subclass that accepts nulls will be > >> unpopular - null elements have fallen out of favor. > >> > >> While|Deque|implementations are not strictly required to prohibit the > insertion > >> of null elements, they are strongly encouraged to do so. Users of > >> any|Deque|implementations that do allow null elements are strongly > >> encouraged/not/to take advantage of the ability to insert nulls. This is so > >> because|null|is used as a special return value by various methods to > indicate > >> that the deque is empty. > >> > >> --- > >> > >> It makes some sense for ArrayDeque's growth policy to be very similar to > >> ArrayList's - that should be done as an independent change. Are there > any > >> lessons to be learned from ArrayList's experience? Is the world filled with > >> empty ArrayDeques that could share a common backing array? > >> > >> --- > >> > >> I do like the idea of having ArrayDeque's List-implementing subclass be a > >> nestmate of ArrayDeque, to share implementation details and to help > discovery > >> and naming. I'm not thrilled with reusing "List" in ArrayDeque.List but I > don't > >> have a great alternative to suggest. > >> > >> > >> On Mon, Jul 16, 2018 at 10:36 AM, Alex Foster > <alexfoster(a)hotmail.ca<mailto:alexfoster@hotmail.ca> > >> <mailto:alexfoster@hotmail.ca>> wrote: > >> > >> Hi again, > >> > >> I updated ArrayDeque with your last idea (adding all list methods but > not > >> implementing List) and added a subclass ArrayDeque.List which > overrides > >> equals and hashcode and implements List. There is also a subclass > >> ArrayDeque.WithNulls that accepts null elements. ArrayDeque has > removeAt(int > >> index) instead of remove(index) to avoid overloading remove(Object). > >> > >> I also added shared empty arrays similar to Arraylist, and a reallocate > >> method which can do the same things as trimToSize and ensure capacity > in > >> Arraylist. It also allows you to trim to a specific capacity other than the > >> size or skip trimming if the capacity is within a specified distance of the > >> target capacity. > >> > >> Also the bulk add methods call collection.toArray, then check the array > for > >> illegal elements, then add the array, which means that a collection could > >> keep the array it returns from toArray and modify it from another > thread > >> after it has been checked but before it has been added which could lead > to > >> illegal elements being added to the ArrayDeque. We could maybe avoid > this by > >> cloning the array or checking the elements after adding them but I'm > not > >> sure if it's worth it... > >> > >> What do you think? > >> > >> I also changed the WhiteBox test a bit: > >> > >> --- a/test/jdk/java/util/ArrayDeque/WhiteBox.java > >> +++ b/test/jdk/java/util/ArrayDeque/WhiteBox.java > >> @@ -88,7 +88,10 @@ > >> > >> @Test > >> public void defaultConstructor() { > >> - checkCapacity(new ArrayDeque(), 16); > >> + ArrayDeque d = new ArrayDeque(); > >> + d.add(new Object()); > >> + d.clear(); > >> + checkCapacity(d, 16); > >> } > >> > >> @Test > >> @@ -131,7 +134,7 @@ > >> if (rnd.nextBoolean()) d.add(99); > >> ArrayDeque clone = serialClone(d); > >> assertInvariants(clone); > >> - assertNotSame(elements(d), elements(clone)); > >> + assertTrue(d.isEmpty() || elements(d) != elements(clone)); > >> assertEquals(d, clone); > >> } > >> } > >> > >> Alex > >> > >> > > > > > End of core-libs-dev Digest, Vol 135, Issue 86 > **********************************************

1 0