BTW,
What is the best way to access command line options from within
visitor classes? JJSCompiler has them, but it seems you cannot reach
the JJSOptions via a JProgram reference, which means you'd have to
patch JJSCompiler everytime you add an option to pass the options to
the visitors as parameters or fields.
-Ray
On Thu, Jan 29, 2009 at 12:41 PM, Ray Cromwell <cromwell...@gmail.com> wrote:
> I just looked at doing this. The first target seems to be in GenerateJavaAST:
>
> private JExpression maybeCast(JType expected, JExpression expression) {
> if (expected != expression.getType()) {
> // Must be a generic; insert a cast operation.
> JReferenceType toType = (JReferenceType) expected;
> return new JCastOperation(program, expression.getSourceInfo(), toType,
> expression);
> } else {
> return expression;
> }
> }
>
> If I add a check for an option, and make this routine a no-op, is it
> going to work, or break something? Alternatively, I can replace calls
> to canCastUnsafe/dynamicCast with no-ops further down in the
> processing and get rid of all casts.
>
> The setCheck code appears to be in ArrayNormalizer:
>
> /*
> * See if we need to do a checked store. Primitives and (effectively)
> * final are statically correct.
> */
> if (elementType instanceof JReferenceType) {
> if (!((JReferenceType) elementType).isFinal()
> || elementType != x.getRhs().getType()) {
> // replace this assignment with a call to setCheck()
> JMethodCall call = new JMethodCall(program, x.getSourceInfo(),
> null, setCheckMethod);
> call.getArgs().add(arrayRef.getInstance());
> call.getArgs().add(arrayRef.getIndexExpr());
> call.getArgs().add(x.getRhs());
> ctx.replaceMe(call);
> }
> }
>
> Seems easy to preference the outer-conditional here with
> "arrayTypeCheckOption.isSkipTypeCheckEnabled()"
>
>
> The latter two, I'm not exactly sure of the semantics you're asking
> for. Seems like eagerly evaluating clinits could be complicated,
> especially if someone is counting on their deferment and
> order-of-evaluation properties. I think you'd need a control flow
> graph to do it properly.
>
> What does obfuscated class literals mean? Do you mean obfuscating the
> packagename/classname/supername passed into the createForClass method?
>
> I have noticed a huge number of getClass() methods in my output
> Javascript, the vast majority of them unused. They can't be pruned it
> appears because of invocations on Object.getClass(), which rescues all
> of them. There are only 4 calls to Object.getClass() in my output it
> appears. The first is in the default toString() method. The second is
> in RuntimeException.getName(). The third is safety checks in arraycopy
> (could also eliminate in an optimization mode) I could do without
> either of these in OBF mode. The fourth is in serialization code.
> Reducing these is something to think about.
>
> -Ray
>
>
>
> On Thu, Jan 29, 2009 at 11:35 AM, Bruce Johnson <br...@google.com> wrote:
>> Does anybody actually have a patch that does any of this? I'd love to see
>> numbers on flags like:
>>
>> -Xopt:skipGenericCasts
>> -Xopt:skipArrayElemTypechecks
>> -Xopt:eagerClinits
>> -Xopt:obfuscatedClassLiterals
>>
>> I think there's a bunch of pretty low-hanging fruit here.
>>
>> On Fri, Jan 23, 2009 at 5:10 PM, Andrés Testi <andres.a.te...@gmail.com>
>> wrote:
>>>
>>> Ray:
>>>
>>> What happends if you extends ArrayList to avoid generics?:
>>>
>>> class RangeAxisArrayList extends ArrayList<RangeAxis>{}
>>>
>>> - Andrés
>>>
>>> On 23 ene, 16:52, Ray Cromwell <cromwell...@gmail.com> wrote:
>>> > Here's the scoop. I changed a field in Chronoscope from RangeAxis[] to
>>> > List<RangeAxis> and suffered ~50% performance regression. An Axis is a
>>> > class
>>> > responsible for mapping values in the range [low, high] to [0,1], among
>>> > other things, so it is a hot class/method in Chronoscope. After
>>> > profiling, I
>>> > noticed the method was no longer being inlined, and a huge number of
>>> > calls
>>> > to dynamicCast/canCastUnsafe appeared. This brings to mind two
>>> > optimizations:
>>> >
>>> > 1) if a method's return type is covariant in a generic type, do not
>>> > insert a
>>> > cast or cast check. Assume that the method *will* return objects of this
>>> > type at the callsite.
>>> > 2) eliminate dynamicCast/canCastUnsafe altogether. These methods only
>>> > exist
>>> > to throw class cast exceptions. I can't believe that there's any code
>>> > that
>>> > actually expects these exceptions and depends on them being thrown
>>> > except
>>> > perhaps unit tests. Anyone running unit tests or UI tests in hosted mode
>>> > will get these exceptions during development, so it seems the only use
>>> > case
>>> > might be web-mode unit tests.
>>> >
>>> > But for production deployed code, dynamicCast/canCaseUnsafe/setCheck/et
>>> > al
>>> > seem to just be bloat and a performance hit to boot. Can we get a
>>> > compile
>>> > mode that removes them? Maybe an -XX method, or some other mechanism
>>> > which
>>> > says "I want potentially unsafe, but super fast code"?
>>> >
>>> > -Ray
>>>
>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
