subprocess isn't very friendly to implementations with different GCs then CPython and in general relies on behavior that's not going to be very stable.  I noticed the following issues but was able to work around all of them.

First Popen is a finalizable object which holds onto another finalizable object (the process handle).  In __del__ Popen calls internal poll which attempts to wait on the handle.  But because both the handle and the POpen object can go out of scope at the same time the handle can be finalized first.  The end result is that you cannot get the return code and therefore the Popen class will resurrect it's self.  That will at the very least leak the Popen object and when running the subprocess tests will eventually start failing all of the tests.  For me this was happening because test_cwd doesn't call wait and therefore never explicitly gets the exit code.

Resurrecting finalizable objects seems like a pretty bad idea and seems to be there only for test purposes - after all who cares if you collect the exit code after no one refers to the object.  Unless _active is supposed to be publicly exposed?  

Another issue is relying on CPython's reference counting garbage collcetion.  In particular _get_handles on Windows does "p2cread = self._make_inheritable(p2cread)" where stdin == PIPE.  On CPython this is going to remove the 1 reference to the previous p2cread and close it immediately.  With other GCs this reference will linger around only to be closed at some point.  Usually that's not a problem but because this handle remains in the parent process the pipe does not get closed when it should resulting in hangs.  This is effectively a duplicated handle of the handle _execute_child closes after the child is launched.