Yes, you are correct. There are two levels of optimization applied: one by the bytecode compiler and the other one by the JIT compiler.
So, I correct my earlier statement: the DEBUG and assert guards don't look similar at the bytecode level. However, in the end they are optimized away at the native code level just the same. And I do believe the assert guards use a static final constant effectively (massaged by the classloader).
Vlad.
Please respond to emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Sent by: emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: emma-users-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
cc:
Subject: RE: [EMMA-users] User instrumentation
But, an observation:
If I write your example below & compile with javac, the line number table entries & bytecodes for the contents of that if() statement are never written to the .class file by javac.
But I'll hedge and say that perhaps different compilers behave differently. ;)
- Paul
From: emma-users-admin-5NWGOfrQmnd4wTydcyPnfg@public.gmane.orgceforge.net [mailto:emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of vlad-+F+d0juzi95BDgjK7y7TUQ@public.gmane.org
Sent: Thursday, September 23, 2004 9:57 AM
To: emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: [EMMA-users] User instrumentation
Nope, I disagree (about the Boolean.getBoolean("something") part)
The assertion checks indeed check a static final constant and for all intents and purposes it looks like it is initialized to a compile-time constant. The trick for enabling/disabling them is that the classloader massages that field at class loading time. That's why assertion API is somewhat tied into classloading....
So, to the JIT compiler the assertion guard fields don't look any different than my DEBUG example earlier.
Vlad.
Please respond to emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Sent by: emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: emma-users-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
cc:
Subject: RE: [EMMA-users] User instrumentation
*grin*.
Sure. But (I'm annoying, I know) -- we're not talking about static final X = false --- we're talking about static final X = Boolean.getBoolean("something").
This obviously isn't handled by javac at bytecode generation time. But, my understanding is that the JIT compiler does indeed handle it – that the hotspot guys triple checked that it really does work when they added the assertion language feature in 1.4.
- Paul
From: emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:emma-users-admin <at> lists.sourceforge.net] On Behalf Of vlad-+F+d0juzi95BDgjK7y7TUQ@public.gmane.org
Sent: Thursday, September 23, 2004 9:38 AM
To: emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: [EMMA-users] User instrumentation
The compiler hasn't been including bytecode for any branch that is provably unreachable via static analysis since v1.0. That's how a poor man's version of conditional compilation works in Java:
private static final DEBUG = false;
if (DEBUG)
{
... this bytecode will not emitted ...
}
In v1.4 (or 1.3, can't remember now) of the compiler they even started doing this for boolean expressions that involve local variables and not just static final fields init'ed to compile-time expressions. Finally, my (esoteric) coding style of declaring just about everything final is paying off :)....
Vlad.
Please respond to emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Sent by: emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
To: emma-users-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
cc:
Subject: RE: [EMMA-users] User instrumentation
I believe, under the covers, assertions are simply implemented with a private static final boolean inside each class. When it's set to false, the JIT compiler doesn't bother including code for the if() branch.
I doubt there is any need for a JSR for this - it could be done just as easily with a -Demma.enabled=false on the command line.
- Paul
-----Original Message-----
From: emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:emma-users-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Michael.Giroux <at> Bull.com
Sent: Thursday, September 23, 2004 9:12 AM
To: emma-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: RE: [EMMA-users] User instrumentation
> Well the same class files are also used by the
> appserver when we are through with unit testing.
> Rebuilding them with WSAD is really timeconsuming so
> I'd rather not instrument them separately.
>
> Deepu.
I'm starting to see a potential for a new JSR.
With Java assertions, it is possible to embed debug code that has a zero
impact on production environments because the java -da/-ea switch can be
used to disable or enable assertion code. The assertion support allows for
assertions to be enabled/disabled at an individual package and/or class.
It would be handy if assertions had some form of "type" and could be
enabled/disabled within a package by "type". This would allow EMMA to
insert instrumentation as assert statements with a defined "type". Type
could be specified in the form of package names, or perhaps numeric values
as is done with the logging apis. Subsequently, the class file could be
executed with -da for production, -ea:package[types] for code coverage.
Michael
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
EMMA-users mailing list
EMMA-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/emma-users
, but after upgrading my 
RSS Feed