6 Replies Latest reply on May 19, 2011 10:54 AM by IDIOTA

    java.lang.NullPointerException in adobe.abc.GlobalOptimizer

    DigitalArchitectCanada Level 3

      I'm access the GlobalOptimizer directly and passing an ABC dump to it. It works just fine if I pass lets say builtin.abc or something from Tamarin but if I pass in an ABC dump from a SWF compiled in Flash CS5 I get an error. Any ideas? Mainly looking for input from an Adobe employee but if anyone has any knowledge on the situation I'd greatly appreciate it. Thanks!

        • 1. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
          DigitalArchitectCanada Level 3

          Also just a quick note, I've tried this with several different abc dumps from swfs targeting different version of flash, because I thought perhaps it was processing op codes it didn't recognize, same error.

          • 2. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
            DigitalArchitectCanada Level 3

            I can actually also specifically tell you what is failing in GlobalOptimizer. It seems that, loading the builtin base types like ARRAY, INT ect are failing when I try and run optimizer on my swf ABC dumps. So, I figured perhaps I needed to include builtin.abc or playerglobal.abc and I didn't get the null pointer exception, but the optimizer ended up failing after a while from maxing out memory allocation. I gave it 2 gigs to work with on the command line. Anyway the offending line in GlobalOptimizer is:

             

            case OP_pushnan:

            case OP_pushdouble:

            v = e.value;

            tref = NUMBER().ref;   <---------- This one

            break;

             

            And as I said these seem to be types initialized elsewhere, like so:

             

            Type OBJECT()    { return TypeCache.instance().OBJECT;}

            Type FUNCTION()  { return TypeCache.instance().FUNCTION;}

            Type CLASS()     { return TypeCache.instance().CLASS;}

            Type ARRAY()     { return TypeCache.instance().ARRAY;}

            Type INT()       { return TypeCache.instance().INT;}

            Type UINT()      { return TypeCache.instance().UINT;}

            Type NUMBER()    { return TypeCache.instance().NUMBER;}

            Type BOOLEAN()   { return TypeCache.instance().BOOLEAN;}

            Type STRING()    { return TypeCache.instance().STRING;}

            Type NAMESPACE() { return TypeCache.instance().NAMESPACE;}

            Type XML()       { return TypeCache.instance().XML;}

            Type XMLLIST()   { return TypeCache.instance().XMLLIST;}

            Type QNAME()     { return TypeCache.instance().QNAME;}

            Type NULL()      { return TypeCache.instance().NULL;}

            Type VOID()      { return TypeCache.instance().VOID;}

            Type ANY()       { return TypeCache.instance().ANY();}

             

            So basically TypeCache is returning null for all these types and I don't know why. Any advice would be great thanks!

            • 3. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
              DigitalArchitectCanada Level 3

              Okay well I figured out the problem and thought I'd post the solution:

               

              I basically ended up editing the ASC.jar source code and removed the function calls related to verbose mode. It appears that even if the user doesn't activate verbose mode, verbose output data is still collected. When processing, somehow there is a memory leak in this this functionality OR the output data is so great, it crashes java causing random errors, if not, GC memory maxed, max memory general exceptions. The second issue is that my original suspicions were correct about needing to pass in player global or some other ABC file that has an internal definition of base class object. If this is not present, then we GlobalOptimizer will not call TypeCache.setupBuiltins(), because there is no Object class from which to properly build the inheritance chain against.

               

              The solution was to include builtin.abc (which can be obtained from the Adobe Flex SDK svn) and also modify GlobalOptimizer to comment out the verbose function calls. Works great. Now I just need to add in definitions for the new classes in the latest flash player somehow .

              • 4. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
                IDIOTA

                I just found out about this GlobalOptimizer from reading your post. It sounds very interesting. Could you please provide more information on this tool? Like a beginner's guide to GlobalOptimizer, perhaps. Thanks you!

                • 5. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
                  DigitalArchitectCanada Level 3

                  To be honest I don't really know a ton about it. My interest in it were sparked when I found a briefing paper on LLVM.org website about how adobe planned to use GlobalOptimizer for the alchemy compiler. From what I understand, the global optimizer outputted an intermediary representation of the actionscript bytecode passed to it for optimization, and adobe planned on simply converting that output to be code that the LLVM compiler could understand and then perform its optimization techniques on that code in static compilation. This is a hack solution but I believe it was the initial solution used to create the alchemy toolkit. Since then adobe seems to have perfected this process and using it for the packager for iphone as well as (althought not 100% sure) android. If you download and decompile the PFI.jar for (packager for iphone) you'll see there are a ton of new classes added to the actionscript compiler all related to LLVM code generation. Note that in the latest packager for iphone, these classes have been merged into the adobe AIR jar file (I believe it's adt.jar). So what it appears adobe has done is actually written java code to interface with the LLVM for converting the ABC output into LLVM IR. LLVM provides interfaces to do this, and this is the ideal solution since it would make updating the whole toolchain to work with newer released of LLVM much, much easier. This is also why I assume that adobe has stopped updating the alchemy project and I think perhaps the only reason why it's still around is to satisfy the licenses of the LLVM and other various open source apple code they've integrated with. Basically I don't think we're ever going to see an update to the alchemy project again, since now this technology is at the core of the sales for flash (that is, the ability to compile mobile native applications). If any of this was made open source ( the new LLVM class additions to the actionscript compiler) or the existing alchemy project was updated, it would make it far too easy for third party tools to be created for publishing flash native executables to a wide variety of devices, and thus be directly counteractive to the core of adobe's business plan for the flash platform. So yeah, after finding all of this out I pretty much abandoned my research on the GlobalOptimizer and the actionscript compiler. I can tell you this about the GlobalOptimizer, that it needs to be updated, along with classes it uses, to understand new classes available in the latest version of the actionscript 3 language. For example if you were to grab the OPEN source of the actionscript compiler, and run global optimizer on an ABC file that target flash 10+ and used classes like the Vector class, it would crash (or at least it did when I tried it). That is because the open source versions of this stuff (asc, etc) is purposely left trailing behind what is current in the flash world and legally so, since its all licensed mostly under the mozilla public license. I did start updating the source to do this but honestly there's so many more core types being added and ones that have been added it's not worth the time. Anyway that's all the NFO I've got, hope it helps.

                  • 6. Re: java.lang.NullPointerException in adobe.abc.GlobalOptimizer
                    IDIOTA Level 1

                    Thanks a lot for taking the time to share your findings. Let's hope Adobe would incorporate some of the optimization techniques found in the GlobalOptimizer back to the regular mxmlc.