Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28
I’ll remove the code and elucidate in the commentary. > On Apr 3, 2021, at 8:08 PM, David Holmes wrote: > > On 4/04/2021 12:02 am, Jim Laskey wrote: >> Is it in bad form to declare a #define CLOSE_JIMAGE 0 ? > > Still dead code. > > This is a core-libs style call anyway. > > Cheers, > David > >> On Apr 3, 2021, at 9:49 AM, David Holmes wrote: >>> >>> On 2/04/2021 5:34 pm, Alan Bateman wrote: On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote: >> src/java.base/share/native/libjimage/imageFile.cpp line 219: >> >>> 217: // WARNING: Should never close the jimage file. >>> 218: // Threads may still be running at shutdown. >>> 219: #if 0 >> >> Are you keeping the code in order to re-visit it again? Just wondering >> why it's not deleted. > > Leaving the code as an example of what is required to close in case the > topic gets revisited in the future and I get hit by a bus or dementia. Okay although I assume someone will spot this and be tempted to remove it. >>> >>> I didn't comment on this as I assumed it would contravene core-libs coding >>> guidelines. I'm suprised to see dead code kept this way (there are existing >>> cases elsewhere but it isn't considered good form). Previous code can >>> always be retrieved from the repo history. >>> >>> Cheers, >>> David >>> - PR: https://git.openjdk.java.net/jdk/pull/3304
Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28
On 4/04/2021 12:02 am, Jim Laskey wrote: Is it in bad form to declare a #define CLOSE_JIMAGE 0 ? Still dead code. This is a core-libs style call anyway. Cheers, David On Apr 3, 2021, at 9:49 AM, David Holmes wrote: On 2/04/2021 5:34 pm, Alan Bateman wrote: On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote: src/java.base/share/native/libjimage/imageFile.cpp line 219: 217: // WARNING: Should never close the jimage file. 218: // Threads may still be running at shutdown. 219: #if 0 Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted. Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia. Okay although I assume someone will spot this and be tempted to remove it. I didn't comment on this as I assumed it would contravene core-libs coding guidelines. I'm suprised to see dead code kept this way (there are existing cases elsewhere but it isn't considered good form). Previous code can always be retrieved from the repo history. Cheers, David - PR: https://git.openjdk.java.net/jdk/pull/3304
Re: 8214761: Bug in parallel Kahan summation implementation
Hi Pavel, I think I have the same issue as Chris. The new OCA contributors list [1] is incorrectly linking the user names to GitHub as compared to the old contributors list [2]. It seems the new OCA contributors list is assuming that the GitHub username of past contributors is the same as the username of the project, when they had signed the OCA in the past. When I had signed OCA a few years back for the OpenJFX project, I had provided my username as *anirvan.sarkar*. This was my username on java.net / javafx-jira.kenai.com (the old JIRA for JavaFX project). But my GitHub username is *AnirvanSarkar*, not *anirvan.sarkar* which user does not exist on GitHub. [1] : https://oca.opensource.oracle.com/?ojr=contrib-list [2] : https://oca.opensource.oracle.com/?ojr=old-contrib-list On Sun, 4 Apr 2021 at 03:35, Pavel Rappo wrote: > Hey Chris, > > I don't know exactly what triggers removal of the "oca" and "oca-verify" > labels. The only OCA entry for Chris Dennis I could find [1] had a > different GitHub username. Did you mistype it or it belongs to another > person? Mind you, that person's GitHub page is 404. > > -Pavel > > [1] https://oca.opensource.oracle.com/?ojr=contrib-list > > > On 3 Apr 2021, at 16:12, Chris Dennis wrote: > > > > A gentle prod. Am I misunderstanding procedure here? > > > > From: Chris Dennis > > Date: Monday, March 22, 2021 at 2:28 PM > > To: core-libs-dev > > Subject: 8214761: Bug in parallel Kahan summation implementation > > I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - > but have been stuck waiting on OCA signatory status to be confirmed. Did > something get lost in the shuffle or do I just need to be more patient. > > > > Thanks, > > > > Chris > > -- Anirvan
Re: 8214761: Bug in parallel Kahan summation implementation
I’m pretty certain that is meant to be me but ‘chris_dennis’ is a now defunct java.net username and not a Github one. The username appears in this list https://oca.opensource.oracle.com/?ojr=old-contrib-list#t too as: “Terracotta Inc. (Christopher Dennis), OpenJDK, chris_dennis”. My Github username is tied to the previous commits I’ve authored though: https://github.com/openjdk/jdk/commits?author=chrisdennis. I also believe there should be a signed OCA for my current employer “Software AG” too since I’ve contributed under it to both OpenJDK and JSR-107. Chris From: Pavel Rappo Date: Saturday, April 3, 2021 at 2:35 PM To: Chris Dennis Cc: core-libs-dev Subject: Re: 8214761: Bug in parallel Kahan summation implementation Hey Chris, I don't know exactly what triggers removal of the "oca" and "oca-verify" labels. The only OCA entry for Chris Dennis I could find [1] had a different GitHub username. Did you mistype it or it belongs to another person? Mind you, that person's GitHub page is 404. -Pavel [1] https://oca.opensource.oracle.com/?ojr=contrib-list > On 3 Apr 2021, at 16:12, Chris Dennis wrote: > > A gentle prod. Am I misunderstanding procedure here? > > From: Chris Dennis > Date: Monday, March 22, 2021 at 2:28 PM > To: core-libs-dev > Subject: 8214761: Bug in parallel Kahan summation implementation > I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but > have been stuck waiting on OCA signatory status to be confirmed. Did > something get lost in the shuffle or do I just need to be more patient. > > Thanks, > > Chris
Re: 8214761: Bug in parallel Kahan summation implementation
Hey Chris, I don't know exactly what triggers removal of the "oca" and "oca-verify" labels. The only OCA entry for Chris Dennis I could find [1] had a different GitHub username. Did you mistype it or it belongs to another person? Mind you, that person's GitHub page is 404. -Pavel [1] https://oca.opensource.oracle.com/?ojr=contrib-list > On 3 Apr 2021, at 16:12, Chris Dennis wrote: > > A gentle prod. Am I misunderstanding procedure here? > > From: Chris Dennis > Date: Monday, March 22, 2021 at 2:28 PM > To: core-libs-dev > Subject: 8214761: Bug in parallel Kahan summation implementation > I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but > have been stuck waiting on OCA signatory status to be confirmed. Did > something get lost in the shuffle or do I just need to be more patient. > > Thanks, > > Chris
Re: 8214761: Bug in parallel Kahan summation implementation
A gentle prod. Am I misunderstanding procedure here? From: Chris Dennis Date: Monday, March 22, 2021 at 2:28 PM To: core-libs-dev Subject: 8214761: Bug in parallel Kahan summation implementation I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient. Thanks, Chris
Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28
Is it in bad form to declare a #define CLOSE_JIMAGE 0 ? > On Apr 3, 2021, at 9:49 AM, David Holmes wrote: > > On 2/04/2021 5:34 pm, Alan Bateman wrote: >> On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote: src/java.base/share/native/libjimage/imageFile.cpp line 219: > 217: // WARNING: Should never close the jimage file. > 218: // Threads may still be running at shutdown. > 219: #if 0 Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted. >>> >>> Leaving the code as an example of what is required to close in case the >>> topic gets revisited in the future and I get hit by a bus or dementia. >> Okay although I assume someone will spot this and be tempted to remove it. > > I didn't comment on this as I assumed it would contravene core-libs coding > guidelines. I'm suprised to see dead code kept this way (there are existing > cases elsewhere but it isn't considered good form). Previous code can always > be retrieved from the repo history. > > Cheers, > David > >> - >> PR: https://git.openjdk.java.net/jdk/pull/3304
Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28
On 2/04/2021 5:34 pm, Alan Bateman wrote: On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote: src/java.base/share/native/libjimage/imageFile.cpp line 219: 217: // WARNING: Should never close the jimage file. 218: // Threads may still be running at shutdown. 219: #if 0 Are you keeping the code in order to re-visit it again? Just wondering why it's not deleted. Leaving the code as an example of what is required to close in case the topic gets revisited in the future and I get hit by a bus or dementia. Okay although I assume someone will spot this and be tempted to remove it. I didn't comment on this as I assumed it would contravene core-libs coding guidelines. I'm suprised to see dead code kept this way (there are existing cases elsewhere but it isn't considered good form). Previous code can always be retrieved from the repo history. Cheers, David - PR: https://git.openjdk.java.net/jdk/pull/3304
Faster double parser?
HI all, just aware of this project, https://github.com/wrandelshofer/FastDoubleParser, not sure if it good idea to use this as default Double Parser in JVM?
