An error occurred fetching the project authors.
  1. 19 Feb, 2015 1 commit
  2. 18 Feb, 2015 2 commits
  3. 13 Feb, 2015 3 commits
  4. 12 Feb, 2015 4 commits
  5. 11 Feb, 2015 1 commit
    • Kevin Modzelewski's avatar
      Scan ht_name for heap types · 038eb9de
      Kevin Modzelewski authored
      We weren't scanning it as part of the gc handler, so eventually it would
      get collected and then __name__ would break.  (un)fortunately, in the
      cases that would use it, it looks like it would always get replaced by
      another string (the only thing being allocated out of that size bin?),
      so it would look like the __name__ was just wrong.
      
      Anyway, this should fix interp2.py
      038eb9de
  6. 10 Feb, 2015 1 commit
    • Kevin Modzelewski's avatar
      Let object.__new__ take kwargs · 1427169a
      Kevin Modzelewski authored
      Also, improve rewriting to still be able to rewrite object construction.
      For now, be able to rewrite the case that a function takes kwargs but
      the kwargs is empty.
      
      Also, add an even faster path to typeCallInternal.  This is partially
      obviated by the improved rewriting, but we might as well keep it.
      1427169a
  7. 07 Feb, 2015 3 commits
  8. 06 Feb, 2015 3 commits
    • Kevin Modzelewski's avatar
      Basic 'traceback' object support · e22da6f3
      Kevin Modzelewski authored
      Previously we were just passing around a vector<> of LineInfos; now, they
      get encapsulated in a BoxedTraceback object.  This has a couple benefits:
      1) they can participate in the existing sys.exc_info passing+handling
      2) we can enable a basic form of the traceback module.
      
      2 means that we can finally test our tracebacks support, since I was constantly
      fixing one issue only to break it in another place.
      
      1 means that we now generate the right traceback for the current exception!
      Before this change, the traceback we would generate was determined using a different
      system than the exc_info-based exception raising, so sometimes they would diverge
      and be horribly confusing.
      
      There's a pretty big limitation with the current implementation: our tracebacks
      don't span the right stack frames.  In CPython, a traceback spans the stack frames
      between the raise and the catch, but in Pyston the traceback includes all stack frames.
      It's not easy to provide this behavior, since the tracebacks are supposed to get updated
      as they get rethrown through each stack frame.
      
      We could do some complicated stuff in irgen to make sure this happens.  I think the better
      but more complicated approach is for us to create the custom exception unwinder we've been
      wanting.  This would let us add custom traceback-handling support as we unwound the stack.
      
      Another limitation is that tracebacks are supposed to automatically include a reference
      to the entire frame stack (tb.tb_frame.f_back.f_back.f_back....).  In Pyston, we're not
      automatically generating those frame objects, so we would either need to do that and take
      a perf hit, or (more likely?) generate the frame objects on-demand when they're needed.
      
      It's not really clear that they're actually needed for traceback objects, so I implemented
      a different traceback object API and changed the traceback.py library, under the assumption
      that almost-noone actually deals with the traceback object internals.
      e22da6f3
    • Travis Hance's avatar
      builtin functions · 128cb7c7
      Travis Hance authored
      128cb7c7
    • Kevin Modzelewski's avatar
      Migrate to the CPython file object format · b1e0937b
      Kevin Modzelewski authored
      Trying to patch up our file support so that we match CPython's behavior and
      functionality more closely; this is the first step.
      b1e0937b
  9. 05 Feb, 2015 3 commits
  10. 04 Feb, 2015 1 commit
    • Kevin Modzelewski's avatar
      Intern most codegen strings · 325dbfeb
      Kevin Modzelewski authored
      Most importantly, intern all the strings we put into the AST* nodes.
      (the AST_Module* owns them)
      
      This should save us some memory, but it also improves performance pretty
      substantially since now we can do string comparisons very cheaply.  Performance
      of the interpreter tier is up by something like 30%, and JIT-compilation times
      are down as well (though not by as much as I was hoping).
      
      The overall effect on perf is more muted since we tier out of the interpreter
      pretty quickly; to see more benefit, we'll have to retune the OSR/reopt thresholds.
      
      For better or worse (mostly better IMO), the interned-ness is encoded in the type
      system, and things will not automatically convert between an InternedString and
      a std::string.  It means that this diff is quite large, but it also makes it a lot
      more clear where we are making our string copies or have other room for optimization.
      325dbfeb
  11. 02 Feb, 2015 2 commits
    • Kevin Modzelewski's avatar
      Remove function versions that fail their speculations · b4094e4e
      Kevin Modzelewski authored
      The goal is to not continually call functions that deopt every time,
      since the deopt is expensive.
      
      Right now the threshold is simple: if a function deopts 4 (configurable)
      times, then mark that function version as invalid and force a recompilation
      on the next call.
      b4094e4e
    • Kevin Modzelewski's avatar
      Basic (new) deopt support · 25ac9de4
      Kevin Modzelewski authored
      Old deopt worked by compiling two copies of every BB, one with
      speculations and one without, and stitching the two together.
      This has a number of issues:
      - doubles the amount of code LLVM has to jit
      - can't ever get back on the optimized path
      - doesn't support 'deopt if branch taken'
      - horrifically complex
      - doesn't support deopt from within try blocks
      
      We actually ran into that last issue (see test from previous commit).  So
      rather than wade in and try to fix old-deopt, just start switching to new-deopt.
      
      (new) deopt works by using the frame introspection features, gathering up all
      the locals, and passing them to the interpreter.
      25ac9de4
  12. 29 Jan, 2015 1 commit
  13. 27 Jan, 2015 1 commit
  14. 24 Jan, 2015 1 commit
    • Kevin Modzelewski's avatar
      Implement Python's name mangling · 636aca17
      Kevin Modzelewski authored
      ie names that begin with two underscores but don't end in two underscores have
      the classname added to them.
      
      Do this early on in the pipeline so that all the analyses operate post-mangling.
      
      The implementation is kind of hacky and I couldn't think of a good way to make it
      super systematic; there may be more cases I missed.
      636aca17
  15. 22 Jan, 2015 7 commits
  16. 21 Jan, 2015 1 commit
    • Kevin Modzelewski's avatar
      Change from throwing a Box* to an ExcInfo triple · 44b63a61
      Kevin Modzelewski authored
      ExcInfo is a triple of exc_type, exc_value, exc_traceback -
      analogous to Python's sys.exc_info().  Previously, we were just
      throwing exc_value.
      
      I still don't understand all the rules for when type(exc_value)
      is not necessarily exc_type.  But this also makes it easier to
      pass exc_traceback around, and should make it possible to make
      our handling more consistent.
      
      This commit just changes the runtime; the generated code currently
      still expects a Box* to be thrown and will crash.
      44b63a61
  17. 11 Jan, 2015 2 commits
    • Kevin Modzelewski's avatar
      Make separate getiter() and getPystonIter() · 78dfdfed
      Kevin Modzelewski authored
      Sometimes you want the wrapping behavior or not --
      the builtin iter() function was calling getiter, but shouldn't
      be doing this wrapping.
      78dfdfed
    • Kevin Modzelewski's avatar
      Support StopIteration-based for loop iteration · a14ebbec
      Kevin Modzelewski authored
      At runtime, we can detect if something supports the new Pyston iteration
      protocol (__hasnext__) or not.
      
      Statically, when we lower a for loop, we assume that the iterator supports
      the new protocol, and we can't check it
      
      This commit adds a check to getiter() which wraps a Python-style iterator
      with an IterWrapper which adds the __hasnext__ method.
      a14ebbec
  18. 10 Jan, 2015 3 commits