From sbaiduzh at redhat.com Wed Jul 1 10:32:26 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 01 Jul 2015 12:32:26 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <555D365B.2000105@oracle.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> <4106910.qMKm2oGpkj@thinkpad.hell> <555D365B.2000105@oracle.com> Message-ID: <5593C1BA.4010104@redhat.com> On 21/05/15 03:35, Jonathan Gibbons wrote: > > On 05/20/2015 01:26 AM, Stanislav Baiduzhyi wrote: >> On Wednesday 13 May 2015 10:01:39 Stanislav Baiduzhyi wrote: >>> On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: >>>> There has been some churn recently with respect to the variable >>>> HG_LIST_FROM_COMMIT. >>>> >>>> See >>>> http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 >>>> http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a >>>> >>>> Therefore, I would suggest whether this needs to be re-investigated in >>>> the light of those recent changes. In particular, the tip has changed >>>> since this thread started. >>> Issue still exists in current tip. I've updated the webrev, link is the >>> same: >>> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp >>> -cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arit >>> >>> hmetic/ >> I've experimented more with that empty value check because I still had a >> feeling that it was not logical. Looks like changing from classical shell >> braces [ to double braces [[ solves the issue already, no need for >> additional >> check. So now it's literally 3 bytes change. Please apply it before >> any other >> changes are going upstream. >> > > Interesting. I see the webrev man page specifies the use of [[ ]] > (e.g. here http://www2.research.att.com/sw/download/man/man1/ksh.html) > and I see the webrev script already has other instances of [[ ]]. > > So, the change certainly looks reasonable. Does anyone wish to confirm > this behavior? If no one objects, I'll push the change. Hi Jon, Could you please push the webrev before any other changes came in? Got one more approval and at least one another person reported the behaviour I'm encountering. -- Regards, Stas From jonathan.gibbons at oracle.com Wed Jul 1 11:05:22 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 01 Jul 2015 04:05:22 -0700 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <5593C1BA.4010104@redhat.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> <4106910.qMKm2oGpkj@thinkpad.hell> <555D365B.2000105@oracle.com> <5593C1BA.4010104@redhat.com> Message-ID: <5593C972.6040003@oracle.com> On 07/01/2015 03:32 AM, Stanislav Baiduzhyi wrote: > On 21/05/15 03:35, Jonathan Gibbons wrote: >> >> On 05/20/2015 01:26 AM, Stanislav Baiduzhyi wrote: >>> On Wednesday 13 May 2015 10:01:39 Stanislav Baiduzhyi wrote: >>>> On Tuesday 12 May 2015 17:06:37 Jonathan Gibbons wrote: >>>>> There has been some churn recently with respect to the variable >>>>> HG_LIST_FROM_COMMIT. >>>>> >>>>> See >>>>> http://hg.openjdk.java.net/code-tools/webrev/rev/935f1eaa4691 >>>>> http://hg.openjdk.java.net/code-tools/webrev/rev/09eb35524f9a >>>>> >>>>> Therefore, I would suggest whether this needs to be >>>>> re-investigated in >>>>> the light of those recent changes. In particular, the tip has >>>>> changed >>>>> since this thread started. >>>> Issue still exists in current tip. I've updated the webrev, link is >>>> the >>>> same: >>>> https://e5decb045a719fb58df46fd7e03c2f98cddc1ac6.googledrive.com/host/0B5Kp >>>> >>>> -cB1sXJrfk9NQTVHMTJTdWpYX3dWaExreWN0V0hQZ3d0eGIyZDltdHBCbmhYcXpzRFk/fix-arit >>>> >>>> >>>> hmetic/ >>> I've experimented more with that empty value check because I still >>> had a >>> feeling that it was not logical. Looks like changing from classical >>> shell >>> braces [ to double braces [[ solves the issue already, no need for >>> additional >>> check. So now it's literally 3 bytes change. Please apply it before >>> any other >>> changes are going upstream. >>> >> >> Interesting. I see the webrev man page specifies the use of [[ ]] >> (e.g. here http://www2.research.att.com/sw/download/man/man1/ksh.html) >> and I see the webrev script already has other instances of [[ ]]. >> >> So, the change certainly looks reasonable. Does anyone wish to confirm >> this behavior? If no one objects, I'll push the change. > > Hi Jon, > > Could you please push the webrev before any other changes came in? Got > one more approval and at least one another person reported the > behaviour I'm encountering. > Done, sorry for delay. -- Jon From sbaiduzh at redhat.com Wed Jul 1 11:08:45 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 01 Jul 2015 13:08:45 +0200 Subject: Webrev: "arithmetic syntax error" when working with non-commited changes In-Reply-To: <5593C972.6040003@oracle.com> References: <1952342.tG88LHOKTp@thinkpad.hell> <5552958D.2090805@oracle.com> <8626727.vX7Ee776rh@thinkpad.hell> <4106910.qMKm2oGpkj@thinkpad.hell> <555D365B.2000105@oracle.com> <5593C1BA.4010104@redhat.com> <5593C972.6040003@oracle.com> Message-ID: <5593CA3D.1070706@redhat.com> On 01/07/15 13:05, Jonathan Gibbons wrote: >> Hi Jon, >> >> Could you please push the webrev before any other changes came in? Got >> one more approval and at least one another person reported the >> behaviour I'm encountering. >> > > Done, sorry for delay. Thanx! Commit message looks especially interesting :) -- Regards, Stas From aleksey.shipilev at oracle.com Wed Jul 1 14:15:49 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 01 Jul 2015 17:15:49 +0300 Subject: CodeTools proposal: "fjptrace" Message-ID: <5593F615.4010103@oracle.com> Tool Name: Java Fork/Join Trace (fjptrace) Tool Purpose: Java Fork/Join Trace (fjptrace) is an instrumented ForkJoinPool implementation that produces the event trace, plus a set of trace visualizers. Proposed By: Aleksey Shipilev, Oracle, Java SE Performance team Rationale: Java Fork/Join Trace is a tool to understand the end-to-end behavior of java.util.concurrent.ForkJoinPool (FJP). It was a foundational tracing tool that exposed problems and outlined the solutions in FJP during the early Project Lambda work. Since FJP became implicitly exposed to users as the executor for Parallel Streams in JDK 8, some users started to have problems following up on performance problems. With fjptrace as part of the OpenJDK CodeTools Project, we can provide the tooling to let users introspect the FJP behavior, as well as produce the high-quality performance bug reports with the data backed up by fjptrace data. Thanks, -Aleksey From jonathan.gibbons at oracle.com Wed Jul 1 21:08:16 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 01 Jul 2015 14:08:16 -0700 Subject: hg: code-tools/webrev: commit.txt In-Reply-To: <201507011104.t61B4reo008177@aojmv0008.oracle.com> References: <201507011104.t61B4reo008177@aojmv0008.oracle.com> Message-ID: <559456C0.8080207@oracle.com> On 07/01/2015 04:04 AM, jonathan.gibbons at oracle.com wrote: > Changeset: 4a617671848f > Author: jjg > Date: 2015-07-01 03:54 -0700 > URL: http://hg.openjdk.java.net/code-tools/webrev/rev/4a617671848f > > commit.txt > > ! webrev.ksh > My apologies for the incorrect commit message. The commit message should have read: 7901458: "arithmetic syntax error" when working with non-commited changes Contributed-by: sbaiduzh at redhat.com -- Jon From aleksey.shipilev at oracle.com Thu Jul 9 12:49:08 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 09 Jul 2015 15:49:08 +0300 Subject: CodeTools proposal: "fjptrace" In-Reply-To: <5593F615.4010103@oracle.com> References: <5593F615.4010103@oracle.com> Message-ID: <559E6DC4.9020100@oracle.com> Any comments? Thanks, -Aleksey On 01.07.2015 17:15, Aleksey Shipilev wrote: > Tool Name: > Java Fork/Join Trace (fjptrace) > > Tool Purpose: > Java Fork/Join Trace (fjptrace) is an instrumented ForkJoinPool > implementation that produces the event trace, plus a set of trace > visualizers. > > Proposed By: > Aleksey Shipilev, Oracle, Java SE Performance team > > Rationale: > Java Fork/Join Trace is a tool to understand the end-to-end behavior of > java.util.concurrent.ForkJoinPool (FJP). It was a foundational tracing > tool that exposed problems and outlined the solutions in FJP during the > early Project Lambda work. > > Since FJP became implicitly exposed to users as the executor for > Parallel Streams in JDK 8, some users started to have problems following > up on performance problems. > > With fjptrace as part of the OpenJDK CodeTools Project, we can provide > the tooling to let users introspect the FJP behavior, as well as produce > the high-quality performance bug reports with the data backed up by > fjptrace data. > > Thanks, > -Aleksey > From jonathan.gibbons at oracle.com Thu Jul 9 18:00:12 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 09 Jul 2015 11:00:12 -0700 Subject: CodeTools proposal: "fjptrace" In-Reply-To: <559E6DC4.9020100@oracle.com> References: <5593F615.4010103@oracle.com> <559E6DC4.9020100@oracle.com> Message-ID: <559EB6AC.7040809@oracle.com> Looks good to me. -- Jon On 07/09/2015 05:49 AM, Aleksey Shipilev wrote: > Any comments? > > Thanks, > -Aleksey > > On 01.07.2015 17:15, Aleksey Shipilev wrote: >> Tool Name: >> Java Fork/Join Trace (fjptrace) >> >> Tool Purpose: >> Java Fork/Join Trace (fjptrace) is an instrumented ForkJoinPool >> implementation that produces the event trace, plus a set of trace >> visualizers. >> >> Proposed By: >> Aleksey Shipilev, Oracle, Java SE Performance team >> >> Rationale: >> Java Fork/Join Trace is a tool to understand the end-to-end behavior of >> java.util.concurrent.ForkJoinPool (FJP). It was a foundational tracing >> tool that exposed problems and outlined the solutions in FJP during the >> early Project Lambda work. >> >> Since FJP became implicitly exposed to users as the executor for >> Parallel Streams in JDK 8, some users started to have problems following >> up on performance problems. >> >> With fjptrace as part of the OpenJDK CodeTools Project, we can provide >> the tooling to let users introspect the FJP behavior, as well as produce >> the high-quality performance bug reports with the data backed up by >> fjptrace data. >> >> Thanks, >> -Aleksey >> > From aleksey.shipilev at oracle.com Thu Jul 9 18:29:54 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 09 Jul 2015 21:29:54 +0300 Subject: CodeTools proposal: "fjptrace" In-Reply-To: <559EB6AC.7040809@oracle.com> References: <5593F615.4010103@oracle.com> <559E6DC4.9020100@oracle.com> <559EB6AC.7040809@oracle.com> Message-ID: <559EBDA2.9050005@oracle.com> Thanks Jon! -Aleksey On 07/09/2015 09:00 PM, Jonathan Gibbons wrote: > Looks good to me. > > -- Jon > > > On 07/09/2015 05:49 AM, Aleksey Shipilev wrote: >> Any comments? >> >> Thanks, >> -Aleksey >> >> On 01.07.2015 17:15, Aleksey Shipilev wrote: >>> Tool Name: >>> Java Fork/Join Trace (fjptrace) >>> >>> Tool Purpose: >>> Java Fork/Join Trace (fjptrace) is an instrumented ForkJoinPool >>> implementation that produces the event trace, plus a set of trace >>> visualizers. >>> >>> Proposed By: >>> Aleksey Shipilev, Oracle, Java SE Performance team >>> >>> Rationale: >>> Java Fork/Join Trace is a tool to understand the end-to-end behavior of >>> java.util.concurrent.ForkJoinPool (FJP). It was a foundational tracing >>> tool that exposed problems and outlined the solutions in FJP during the >>> early Project Lambda work. >>> >>> Since FJP became implicitly exposed to users as the executor for >>> Parallel Streams in JDK 8, some users started to have problems following >>> up on performance problems. >>> >>> With fjptrace as part of the OpenJDK CodeTools Project, we can provide >>> the tooling to let users introspect the FJP behavior, as well as produce >>> the high-quality performance bug reports with the data backed up by >>> fjptrace data. >>> >>> Thanks, >>> -Aleksey >>> >> > From kevin.looney at oracle.com Thu Jul 9 21:18:59 2015 From: kevin.looney at oracle.com (Kevin Looney) Date: Thu, 09 Jul 2015 14:18:59 -0700 Subject: CodeTools proposal: "fjptrace" In-Reply-To: <559E6DC4.9020100@oracle.com> References: <5593F615.4010103@oracle.com> <559E6DC4.9020100@oracle.com> Message-ID: <559EE543.2030908@oracle.com> I'd say it sounds appropriate for CodeTools. Kevin L On 7/9/15 5:49 AM, Aleksey Shipilev wrote: > Any comments? > > Thanks, > -Aleksey > > On 01.07.2015 17:15, Aleksey Shipilev wrote: >> Tool Name: >> Java Fork/Join Trace (fjptrace) >> >> Tool Purpose: >> Java Fork/Join Trace (fjptrace) is an instrumented ForkJoinPool >> implementation that produces the event trace, plus a set of trace >> visualizers. >> >> Proposed By: >> Aleksey Shipilev, Oracle, Java SE Performance team >> >> Rationale: >> Java Fork/Join Trace is a tool to understand the end-to-end behavior of >> java.util.concurrent.ForkJoinPool (FJP). It was a foundational tracing >> tool that exposed problems and outlined the solutions in FJP during the >> early Project Lambda work. >> >> Since FJP became implicitly exposed to users as the executor for >> Parallel Streams in JDK 8, some users started to have problems following >> up on performance problems. >> >> With fjptrace as part of the OpenJDK CodeTools Project, we can provide >> the tooling to let users introspect the FJP behavior, as well as produce >> the high-quality performance bug reports with the data backed up by >> fjptrace data. >> >> Thanks, >> -Aleksey >> > -- kevin.looney at oracle.com