I hope Google takes out an extra insurance policy so that should an accident occur, they can cryogenically freeze your brain and thaw you out in the future in case there are any outstanding compiler issues no one has been able to fix. :) -Ray
On Thu, Apr 9, 2009 at 10:24 AM, Scott Blum <[email protected]> wrote: > Don't worry, I'm getting plenty of naps in during the hour-long hyperbaric > sessions I do with Aaron. Which is, good, since we have to get up at 7 to > make the morning ones. :) But we're having some fun too. Aaron and I just > got back from hanging out at the pool and soaking up some sun. Aaron > preferred to lay on the lounge chairs with a shirt over his head, while I > did laps around the pool on my Ripstick. > > > On Thu, Apr 9, 2009 at 12:37 PM, Bruce Johnson <[email protected]> wrote: > >> w00t! Vacation commits FTW! (Just kidding; @Scott: please rest) >> >> >> On Thu, Apr 9, 2009 at 11:52 AM, Scott Blum <[email protected]> wrote: >> >>> FYI: I just committed the last of my outstanding memory work to trunk. >>> Lex kindly agreed to watch the build and do a roll-back for me if something >>> breaks. >>> >>> >>> On Tue, Apr 7, 2009 at 10:33 PM, Scott Blum <[email protected]> wrote: >>> >>>> On Tue, Apr 7, 2009 at 4:12 PM, Lex Spoon <[email protected]> wrote: >>>> >>>>> > 5178: Also tightened up the recursive method slightly, and managing >>>>> the >>>>> > "computed" set better. This works because once a class transitions >>>>> from >>>>> > hasClinit -> !hasClinit, there's no possible way it can ever go back. >>>>> >>>>> Small problem: I believe line 644-646 in the patched version is >>>>> intended to test "target", not "type". If that sounds right, then the >>>>> rest LGTM. Otherwise, let's discuss how this is supposed to work. >>>>> >>>> >>>> Nice catch! I botched a manual inlining of lines 636-641 in the >>>> original. >>>> >>>> >>>>> By the way, this algorithm could be sped up if, it mattered for >>>>> performance. Instead of repeatedly recursing for each type, start by >>>>> marking classes where hasLiveCode() as having clinits. Then, >>>>> propagate clinit-ness backwards along the getClinitTargets() graph. >>>>> Any class not reached does not needs its clinit. The advantage >>>>> probably doesn't matter in this case in practice, but I mention it >>>>> because this funny algorithm pattern keeps coming up. >>>>> >>>> >>>> That is a better approach, I'll have to remember that next time I run >>>> into this pattern. >>>> >>>> Thanks, >>>> Scott >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
