- 14 Feb, 2015 5 commits
-
-
Kevin Modzelewski authored
Fully switch to the new deopt system, and clean up a lot of stuff.
-
Kevin Modzelewski authored
A "FunctionSpecialization" object really makes no sense in the context of an OSR compile, since the FunctionSpecialization talks about the types of the input arguments, which no longer matter for OSR compiles. Now, their type information comes (almost) entirely from the OSREntryDescriptor, so in most places assert that we get exactly one or the other.
-
Kevin Modzelewski authored
We only needed that for supporting the old deopt system
-
Kevin Modzelewski authored
Long live new-deopt!
-
Kevin Modzelewski authored
Before we would do type analysis starting from the function entry (using the specialization of the previous function). This makes things pretty complicated because we can infer different types than we are OSRing with! Ex if the type analysis determines that we should speculate in an earlier BB, the types we have now might not reflect that speculation. So instead, start the type analysis starting from the BB that the OSR starts at. Should also have the side-benefit of requiring less type analysis work. But this should let us get rid of the OSR-entry guarding, and the rest of the old deopt system!
-
- 13 Feb, 2015 26 commits
-
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
add a simple_destructor for file objects
-
Kevin Modzelewski authored
Add third GC arena
-
Kevin Modzelewski authored
Previously it was: tier 0: ast interpreter tier 1: llvm, no speculations, no llvm opts tier 2: llvm, w/ speculations, no llvm opts tier 3: llvm, w/ speculations, w/ llvm opts tier 2 seemed pretty useless, and very little would stay in it. Also, OSR would always skip from tier 1 to tier 3. Separately, add configurable OSR/reopt thresholds. This is mostly for the sake of tests, where we can set lower limits and force OSR/reopts to happen.
-
Chris Toshok authored
-
Kevin Modzelewski authored
-
Chris Toshok authored
-
Kevin Modzelewski authored
Generator tracebacks
-
Kevin Modzelewski authored
add reversed() builtin function, as well as compatible __reversed__ methods on list/xrange.
-
Chris Toshok authored
-
Chris Toshok authored
-
Chris Toshok authored
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Fix: GC must visit the 'iter' field of every BoxedIterWrapper
-
Chris Toshok authored
-
Marius Wachtler authored
-
Marius Wachtler authored
-
Kevin Modzelewski authored
(previously we would just throw an assert)
-
Chris Toshok authored
-
Chris Toshok authored
-
Chris Toshok authored
add a comment about further work for realloc(), and factor out the duplicate list.forEach in large/huge arenas
-
Chris Toshok authored
-
Chris Toshok authored
-
Chris Toshok authored
-
Chris Toshok authored
don't use toggle, since our assert ensures not free only in debug builds. also, more valgrind error disabling for access to the GCAllocation data
-
Chris Toshok authored
port over sgen's idea of LOSSections as a mid-sized arena, so that we now have: SmallArena original non-large allocator, free bitmaps, segregated-fit allocator. handles objects where size <= 3584 bytes LargeArena (new code, size-specific free lists.) handles object where 3584 < size <= ~1 meg HugeArena (original large allocator, 1 mmap per object. handles objects where size > ~1meg
-
- 12 Feb, 2015 9 commits
-
-
Kevin Modzelewski authored
Implement str.join(iterable)
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
We were having problems with spawning subprocesses from threads, since the children would inherit the "wait for another thread to acquire the gil" flag, but would not inherit the thread that would actually try to acquire the gil; this would make the child hang.
-
Marius Wachtler authored
-
Marius Wachtler authored
before we stopped at the generatorEntry func and did not unwind into the caller.
-
Kevin Modzelewski authored
Also, register string memory as additional GC pressure. The subprocess module repeatedly allocates a 1MB str as a buffer for reading from file descriptors. The first issue was that we would never free this memory; but even once we would, we wouldn't trigger a GC since there were only small GC allocations (sizeof(BoxedString) at a time) but with large other memory pressure, so add a hook for adding GC pressure.
-
Kevin Modzelewski authored
We don't call pthread_join on the threads we create, so apparently unless we call pthread_detach we just don't get the resources back (ex stack memory).
-
Kevin Modzelewski authored
This doesn't handle all the cases that CPython does.
-
Kevin Modzelewski authored
And fix a bunch of places that they weren't.
-