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.hol...@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.r...@oracle.com >> <mailto:john.r.r...@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 >> >>
