Re: cost of Java "assert" when disabled?
The corelibs side of things seems to have gotten dropped from the cc list - added back. On 17/02/2012 8:21 AM, Vitaly Davidovich wrote:
Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot.
But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list. So summary is: - Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions David
Sent from my phone
On Feb 16, 2012 5:14 PM, "John Rose" <john.r.rose@oracle.com <mailto:john.r.rose@oracle.com>> wrote:
On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote:
I think one problem with them is that they count towards the inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays.
Optimized object code has (probably) no trace of the assertions themselves, but as Vitaly said, they perturb the inlining budget. Larger methods have a tendency to "discourage" the inliner from inlining, causing more out-of-line calls and a rough net slowdown. Currently, the non-executed bytecodes for assertions (which can be arbitrarily complex) make methods look bigger than they really are. This is (IMO) a bug in the inlining heuristics, which should be fixed by examining inlining candidates with a little more care. Since the escape analysis does a similar method summarization, there isn't necessarily even a need for an extra pass over the methods.
-- John
The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of code with condition, etc. There are workarounds, but it's not ideal. C#/.Net have conditional compilation (conditional blocks + assert statements) and it's a handy tool and no need to worry about dead IL code causing opto issues - don't see a reason why java couldn't have done the same from the beginning. Sent from my phone On Feb 16, 2012 6:16 PM, "David Holmes" <david.holmes@oracle.com> wrote:
The corelibs side of things seems to have gotten dropped from the cc list - added back.
On 17/02/2012 8:21 AM, Vitaly Davidovich wrote:
Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot.
But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list.
So summary is:
- Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions
David
Sent from my phone
On Feb 16, 2012 5:14 PM, "John Rose" <john.r.rose@oracle.com <mailto:john.r.rose@oracle.com**>> wrote:
On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote:
I think one problem with them is that they count towards the
inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays.
Optimized object code has (probably) no trace of the assertions themselves, but as Vitaly said, they perturb the inlining budget. Larger methods have a tendency to "discourage" the inliner from inlining, causing more out-of-line calls and a rough net slowdown. Currently, the non-executed bytecodes for assertions (which can be arbitrarily complex) make methods look bigger than they really are. This is (IMO) a bug in the inlining heuristics, which should be fixed by examining inlining candidates with a little more care. Since the escape analysis does a similar method summarization, there isn't necessarily even a need for an extra pass over the methods.
-- John
On 17/02/2012 9:40 AM, Vitaly Davidovich wrote:
The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of code with condition, etc. There are workarounds, but it's not ideal.
I'm not going to get drawn into the whole "conditional compilation is [not] evil" debate. :) If I recall correctly the suggested buld-time idiom was to do: static final boolean ASSERT = true; // or false ... if (ASSERT) assert ... that way you could compile with ASSERT set true to get assertions in the code; or false to have them elided by javac.
C#/.Net have conditional compilation (conditional blocks + assert statements) and it's a handy tool and no need to worry about dead IL code causing opto issues - don't see a reason why java couldn't have done the same from the beginning.
Simply because the people defining the language didn't want it. I suspect there's a blog or two out there somewhere discussing this. David -----
Sent from my phone On Feb 16, 2012 6:16 PM, "David Holmes"<david.holmes@oracle.com> wrote:
The corelibs side of things seems to have gotten dropped from the cc list - added back.
On 17/02/2012 8:21 AM, Vitaly Davidovich wrote:
Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot.
But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list.
So summary is:
- Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions
David
Sent from my phone
On Feb 16, 2012 5:14 PM, "John Rose"<john.r.rose@oracle.com <mailto:john.r.rose@oracle.com**>> wrote:
On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote:
I think one problem with them is that they count towards the
inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays.
Optimized object code has (probably) no trace of the assertions themselves, but as Vitaly said, they perturb the inlining budget. Larger methods have a tendency to "discourage" the inliner from inlining, causing more out-of-line calls and a rough net slowdown. Currently, the non-executed bytecodes for assertions (which can be arbitrarily complex) make methods look bigger than they really are. This is (IMO) a bug in the inlining heuristics, which should be fixed by examining inlining candidates with a little more care. Since the escape analysis does a similar method summarization, there isn't necessarily even a need for an extra pass over the methods.
-- John
Thanks to all for the prompt and enlightening discussion, and especially to David for the succinct summary. -- ramki On Thu, Feb 16, 2012 at 3:15 PM, David Holmes <david.holmes@oracle.com>wrote:
The corelibs side of things seems to have gotten dropped from the cc list - added back.
On 17/02/2012 8:21 AM, Vitaly Davidovich wrote:
Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot.
But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list.
So summary is:
- Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions
David
Sent from my phone
On Feb 16, 2012 5:14 PM, "John Rose" <john.r.rose@oracle.com <mailto:john.r.rose@oracle.com**>> wrote:
On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote:
I think one problem with them is that they count towards the
inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays.
Optimized object code has (probably) no trace of the assertions themselves, but as Vitaly said, they perturb the inlining budget. Larger methods have a tendency to "discourage" the inliner from inlining, causing more out-of-line calls and a rough net slowdown. Currently, the non-executed bytecodes for assertions (which can be arbitrarily complex) make methods look bigger than they really are. This is (IMO) a bug in the inlining heuristics, which should be fixed by examining inlining candidates with a little more care. Since the escape analysis does a similar method summarization, there isn't necessarily even a need for an extra pass over the methods.
-- John
participants (3)
-
David Holmes
-
Srinivas Ramakrishna
-
Vitaly Davidovich