From shanliang.jiang at oracle.com Tue Aug 20 08:19:07 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 20 Aug 2013 17:19:07 +0200 Subject: jmx-dev Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed Message-ID: <521388EB.8070405@oracle.com> Hi, Please review: webrev: http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ bug: https://jbs.oracle.com/bugs/browse/JDK-6566891 I have passed JCK tests and unit tests. Thanks, Shanliang From shanliang.jiang at oracle.com Tue Aug 20 08:35:06 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 20 Aug 2013 17:35:06 +0200 Subject: jmx-dev Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed In-Reply-To: <521388EB.8070405@oracle.com> References: <521388EB.8070405@oracle.com> Message-ID: <52138CAA.6020600@oracle.com> webrev: http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/ shanliang wrote: > Hi, > > Please review: > > webrev: > http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ > bug: https://jbs.oracle.com/bugs/browse/JDK-6566891 > > I have passed JCK tests and unit tests. > > Thanks, > Shanliang > From shanliang.jiang at oracle.com Mon Aug 26 01:35:34 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 26 Aug 2013 10:35:34 +0200 Subject: jmx-dev Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed In-Reply-To: <521489C6.7010407@oracle.com> References: <521388EB.8070405@oracle.com> <52138CAA.6020600@oracle.com> <52139A46.3010201@oracle.com> <5213DBCF.10802@oracle.com> <5213E6E9.8000408@oracle.com> <52146D74.1000803@oracle.com> <521479DE.8000903@oracle.com> <521489C6.7010407@oracle.com> Message-ID: <521B1356.4010906@oracle.com> Hi, Still need OK from a reviewer. Thanks Erik, Jaroslav and Daniel for the code review. Thanks, Shanliang Daniel Fuchs wrote: > On 8/21/13 10:27 AM, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 08/21/2013 12:00 AM, Daniel Fuchs wrote: >>> >>>> On 8/20/13 11:12 PM, shanliang wrote: >>>> >>>>> Thanks Daniel and Erik for the comments, here is new version: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-6566891/01/ >>>>> >>>> This new version looks reasonable. I guess you could dispense of >>>> the new >>>> nullSubjectConnRef by just using 'null' as key in the WeakHashMap >>>> (as this >>>> seems to be the way it used to work before) - but I'm OK with your >>>> proposed changes. >>>> >>> >>> Indeed, the change could be simplified by just using the null key. >>> >> If using "null" as a key, then the pair null/weakRef will never be >> removed from WeakHashMap, even the value of weakRef is null. Of course >> this is a minor memory leak, or almost nothing, but it seems more clean >> to use nullSubjectConnRef. > > Ah. Good point. I didn't think of that... > >> Still need a reviewer. >> >> Thanks, >> Shanliang >>> The rest seems fine. Thumbs up! >>> >>> -JB- >>> >>> >>>> -- daniel >>>> >>>>> Erik Gahlin wrote: >>>>> >>>>>> Shanliang, >>>>>> >>>>>> Let's say the delgationSubject is null and there is previous >>>>>> connection cached (nullSubjectConn != null && nullSubjectConn.get() >>>>>> != null) so you hit: >>>>>> >>>>>> 2016: conn = nullSubjectConn.get(); >>>>>> >>>>>> but before you get the object a GC occurs and clears reference, then >>>>>> getConnectionWithSubject would return null. >>>>>> >>>>>> Shouldn't you assign to nullSubjectConn.get() to variable so the >>>>>> reference is kept alive? Or it OK to return null? >>>>>> >>>>> Yes, should avoid calling 2 times. >>>>> >>>>>> Also, is the >>>>>> >>>>>> 2020: if (wr != null) { >>>>>> >>>>> This line is no more there. >>>>> >>>>> Shanliang >>>>> >>>>>> necessary? >>>>>> >>>>>> Thanks >>>>>> Erik >>>>>> >>>>>> nullSibwhen you hit the second if-statement >>>>>> happens >>>>>> shanliang skrev 2013-08-20 17:35: >>>>>> >>>>>>> webrev:http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/ >>>>>>> >>>>>>> shanliang wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review: >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ >>>>>>>> >>>>>>>> bug:https://jbs.oracle.com/bugs/browse/JDK-6566891 >>>>>>>> >>>>>>>> I have passed JCK tests and unit tests. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>> >>>>>>>> >>>> >>> >>> >> > From shanliang.jiang at oracle.com Thu Aug 29 00:34:13 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 29 Aug 2013 09:34:13 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE Message-ID: <521EF975.4050803@oracle.com> Hi, Please review following fix, it addresses the issue only in the method "hashCode": bug: https://bugs.openjdk.java.net/browse/JDK-8023669 webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ Thanks, Shanliang From daniel.fuchs at oracle.com Thu Aug 29 02:21:25 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Aug 2013 11:21:25 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <521EF975.4050803@oracle.com> References: <521EF975.4050803@oracle.com> Message-ID: <521F1295.80107@oracle.com> On 8/29/13 9:34 AM, shanliang wrote: > Hi, > > Please review following fix, it addresses the issue only in the method > "hashCode": > bug: https://bugs.openjdk.java.net/browse/JDK-8023669 > webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ > > Thanks, > Shanliang > Hi Shanliang, I suggest to simplify this by calling: public int hashCode() { return Objects.hash(getName(), getType()); } (see ) int hash = getName() == null ? 10 : getName().hashCode(); could be replaced by: int hash = Objects.hashCode(getName()); Generally - and that stands for the other files you modified, you can simplify things by replacing x.hashCode() with Objects.hashCode(x) whenever there's the possibility that x can be null. Note however that Objects is an API @since JDK 7 - so if you intend to backport this fix to 6 & 5 you will need to alter your changeset when backporting it. MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest to use Objects.hash(...); best regards, -- daniel BTW: one more question: you're also testing toString() in the test and that's good - but are there any toString() that will require fixing? From david.holmes at oracle.com Thu Aug 29 04:45:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Aug 2013 21:45:20 +1000 Subject: jmx-dev Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed In-Reply-To: <521B1356.4010906@oracle.com> References: <521388EB.8070405@oracle.com> <52138CAA.6020600@oracle.com> <52139A46.3010201@oracle.com> <5213DBCF.10802@oracle.com> <5213E6E9.8000408@oracle.com> <52146D74.1000803@oracle.com> <521479DE.8000903@oracle.com> <521489C6.7010407@oracle.com> <521B1356.4010906@oracle.com> Message-ID: <521F3450.7010807@oracle.com> Hi Shanliang, After our off-list discussion I've had a closer look at this and it looks okay to me too. Reviewed. Thanks, David On 26/08/2013 6:35 PM, shanliang wrote: > Hi, > > Still need OK from a reviewer. > Thanks Erik, Jaroslav and Daniel for the code review. > > Thanks, > Shanliang > > Daniel Fuchs wrote: >> On 8/21/13 10:27 AM, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> On 08/21/2013 12:00 AM, Daniel Fuchs wrote: >>>> >>>>> On 8/20/13 11:12 PM, shanliang wrote: >>>>> >>>>>> Thanks Daniel and Erik for the comments, here is new version: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-6566891/01/ >>>>>> >>>>> This new version looks reasonable. I guess you could dispense of >>>>> the new >>>>> nullSubjectConnRef by just using 'null' as key in the WeakHashMap >>>>> (as this >>>>> seems to be the way it used to work before) - but I'm OK with your >>>>> proposed changes. >>>>> >>>> >>>> Indeed, the change could be simplified by just using the null key. >>>> >>> If using "null" as a key, then the pair null/weakRef will never be >>> removed from WeakHashMap, even the value of weakRef is null. Of course >>> this is a minor memory leak, or almost nothing, but it seems more clean >>> to use nullSubjectConnRef. >> >> Ah. Good point. I didn't think of that... >> >>> Still need a reviewer. >>> >>> Thanks, >>> Shanliang >>>> The rest seems fine. Thumbs up! >>>> >>>> -JB- >>>> >>>> >>>>> -- daniel >>>>> >>>>>> Erik Gahlin wrote: >>>>>> >>>>>>> Shanliang, >>>>>>> >>>>>>> Let's say the delgationSubject is null and there is previous >>>>>>> connection cached (nullSubjectConn != null && nullSubjectConn.get() >>>>>>> != null) so you hit: >>>>>>> >>>>>>> 2016: conn = nullSubjectConn.get(); >>>>>>> >>>>>>> but before you get the object a GC occurs and clears reference, then >>>>>>> getConnectionWithSubject would return null. >>>>>>> >>>>>>> Shouldn't you assign to nullSubjectConn.get() to variable so the >>>>>>> reference is kept alive? Or it OK to return null? >>>>>>> >>>>>> Yes, should avoid calling 2 times. >>>>>> >>>>>>> Also, is the >>>>>>> >>>>>>> 2020: if (wr != null) { >>>>>>> >>>>>> This line is no more there. >>>>>> >>>>>> Shanliang >>>>>> >>>>>>> necessary? >>>>>>> >>>>>>> Thanks >>>>>>> Erik >>>>>>> >>>>>>> nullSibwhen you hit the second if-statement >>>>>>> happens >>>>>>> shanliang skrev 2013-08-20 17:35: >>>>>>> >>>>>>>> webrev:http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/ >>>>>>>> >>>>>>>> shanliang wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review: >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ >>>>>>>>> >>>>>>>>> bug:https://jbs.oracle.com/bugs/browse/JDK-6566891 >>>>>>>>> >>>>>>>>> I have passed JCK tests and unit tests. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> >>>>> >>>> >>>> >>> >> > From shanliang.jiang at oracle.com Thu Aug 29 04:48:13 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 29 Aug 2013 13:48:13 +0200 Subject: jmx-dev Codereview requested: 6566891 RMIConnector: map value referencing map key in WeakHashMap prevents map entry to be removed In-Reply-To: <521F3450.7010807@oracle.com> References: <521388EB.8070405@oracle.com> <52138CAA.6020600@oracle.com> <52139A46.3010201@oracle.com> <5213DBCF.10802@oracle.com> <5213E6E9.8000408@oracle.com> <52146D74.1000803@oracle.com> <521479DE.8000903@oracle.com> <521489C6.7010407@oracle.com> <521B1356.4010906@oracle.com> <521F3450.7010807@oracle.com> Message-ID: <521F34FD.7060602@oracle.com> Thanks David. Shanliang David Holmes wrote: > Hi Shanliang, > > After our off-list discussion I've had a closer look at this and it > looks okay to me too. > > Reviewed. > > Thanks, > David > > On 26/08/2013 6:35 PM, shanliang wrote: >> Hi, >> >> Still need OK from a reviewer. >> Thanks Erik, Jaroslav and Daniel for the code review. >> >> Thanks, >> Shanliang >> >> Daniel Fuchs wrote: >>> On 8/21/13 10:27 AM, shanliang wrote: >>>> Jaroslav Bachorik wrote: >>>>> On 08/21/2013 12:00 AM, Daniel Fuchs wrote: >>>>> >>>>>> On 8/20/13 11:12 PM, shanliang wrote: >>>>>> >>>>>>> Thanks Daniel and Erik for the comments, here is new version: >>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-6566891/01/ >>>>>>> >>>>>> This new version looks reasonable. I guess you could dispense of >>>>>> the new >>>>>> nullSubjectConnRef by just using 'null' as key in the WeakHashMap >>>>>> (as this >>>>>> seems to be the way it used to work before) - but I'm OK with your >>>>>> proposed changes. >>>>>> >>>>> >>>>> Indeed, the change could be simplified by just using the null key. >>>>> >>>> If using "null" as a key, then the pair null/weakRef will never be >>>> removed from WeakHashMap, even the value of weakRef is null. Of course >>>> this is a minor memory leak, or almost nothing, but it seems more >>>> clean >>>> to use nullSubjectConnRef. >>> >>> Ah. Good point. I didn't think of that... >>> >>>> Still need a reviewer. >>>> >>>> Thanks, >>>> Shanliang >>>>> The rest seems fine. Thumbs up! >>>>> >>>>> -JB- >>>>> >>>>> >>>>>> -- daniel >>>>>> >>>>>>> Erik Gahlin wrote: >>>>>>> >>>>>>>> Shanliang, >>>>>>>> >>>>>>>> Let's say the delgationSubject is null and there is previous >>>>>>>> connection cached (nullSubjectConn != null && >>>>>>>> nullSubjectConn.get() >>>>>>>> != null) so you hit: >>>>>>>> >>>>>>>> 2016: conn = nullSubjectConn.get(); >>>>>>>> >>>>>>>> but before you get the object a GC occurs and clears reference, >>>>>>>> then >>>>>>>> getConnectionWithSubject would return null. >>>>>>>> >>>>>>>> Shouldn't you assign to nullSubjectConn.get() to variable so the >>>>>>>> reference is kept alive? Or it OK to return null? >>>>>>>> >>>>>>> Yes, should avoid calling 2 times. >>>>>>> >>>>>>>> Also, is the >>>>>>>> >>>>>>>> 2020: if (wr != null) { >>>>>>>> >>>>>>> This line is no more there. >>>>>>> >>>>>>> Shanliang >>>>>>> >>>>>>>> necessary? >>>>>>>> >>>>>>>> Thanks >>>>>>>> Erik >>>>>>>> >>>>>>>> nullSibwhen you hit the second if-statement >>>>>>>> happens >>>>>>>> shanliang skrev 2013-08-20 17:35: >>>>>>>> >>>>>>>>> webrev:http://cr.openjdk.java.net/~sjiang/JDK-6566891/00/ >>>>>>>>> >>>>>>>>> shanliang wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review: >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://amos.fr.oracle.com/jmgt/user/sjiang/webrevs/jdk8-6566891/00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> bug:https://jbs.oracle.com/bugs/browse/JDK-6566891 >>>>>>>>>> >>>>>>>>>> I have passed JCK tests and unit tests. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> From shanliang.jiang at oracle.com Thu Aug 29 07:11:35 2013 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 29 Aug 2013 16:11:35 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <521F1295.80107@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> Message-ID: <521F5697.3040108@oracle.com> Here is the new version: http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ Indeed, calling Objects.hash(Object ...) is a good idea, which simplifies the code. I used also Arrays.hashCode() to simplify the code, now the fix likes really simple. I have passed JCK tests, unit tests of management are passed too in my desk. toString() worked perfectly in the test, nothing to fix. Shanliang Daniel Fuchs wrote: > On 8/29/13 9:34 AM, shanliang wrote: >> Hi, >> >> Please review following fix, it addresses the issue only in the method >> "hashCode": >> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >> >> Thanks, >> Shanliang >> > > Hi Shanliang, > > > > > I suggest to simplify this by calling: > > public int hashCode() { > return Objects.hash(getName(), getType()); > } > > (see > ) > > > > > > int hash = getName() == null ? 10 : getName().hashCode(); > > could be replaced by: > > int hash = Objects.hashCode(getName()); > > Generally - and that stands for the other files you modified, you can > simplify things by replacing x.hashCode() with Objects.hashCode(x) > whenever there's the possibility that x can be null. > > Note however that Objects is an API @since JDK 7 - so if you intend > to backport this fix to 6 & 5 you will need to alter your changeset > when backporting it. > > > MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest > to use Objects.hash(...); > > best regards, > > -- daniel > > BTW: one more question: you're also testing toString() in the test > and that's good - but are there any toString() that will require > fixing? > > From daniel.fuchs at oracle.com Thu Aug 29 07:43:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Aug 2013 16:43:08 +0200 Subject: jmx-dev Codereview request for JDK-8023669: MBean*Info.hashCode : NPE In-Reply-To: <521F5697.3040108@oracle.com> References: <521EF975.4050803@oracle.com> <521F1295.80107@oracle.com> <521F5697.3040108@oracle.com> Message-ID: <521F5DFC.5050600@oracle.com> On 8/29/13 4:11 PM, shanliang wrote: > Here is the new version: > http://cr.openjdk.java.net/~sjiang/jdk-8023669/01/ > > Indeed, calling Objects.hash(Object ...) is a good idea, which > simplifies the code. > > I used also Arrays.hashCode() to simplify the code, now the fix likes > really simple. > > I have passed JCK tests, unit tests of management are passed too in my > desk. > > toString() worked perfectly in the test, nothing to fix. > > Shanliang Hi Shanliang, This looks good! Thumbs up! -- daniel > > Daniel Fuchs wrote: >> On 8/29/13 9:34 AM, shanliang wrote: >>> Hi, >>> >>> Please review following fix, it addresses the issue only in the method >>> "hashCode": >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023669 >>> webrev: http://cr.openjdk.java.net/~sjiang/jdk-8023669/00/ >>> >>> Thanks, >>> Shanliang >>> >> >> Hi Shanliang, >> >> >> >> >> I suggest to simplify this by calling: >> >> public int hashCode() { >> return Objects.hash(getName(), getType()); >> } >> >> (see >> ) >> >> >> >> >> >> int hash = getName() == null ? 10 : getName().hashCode(); >> >> could be replaced by: >> >> int hash = Objects.hashCode(getName()); >> >> Generally - and that stands for the other files you modified, you can >> simplify things by replacing x.hashCode() with Objects.hashCode(x) >> whenever there's the possibility that x can be null. >> >> Note however that Objects is an API @since JDK 7 - so if you intend >> to backport this fix to 6 & 5 you will need to alter your changeset >> when backporting it. >> >> >> MBeanOperationInfo.java, MBeanParameterInfo.java: I suggest >> to use Objects.hash(...); >> >> best regards, >> >> -- daniel >> >> BTW: one more question: you're also testing toString() in the test >> and that's good - but are there any toString() that will require >> fixing? >> >> >