The benchmark works as far as I can tell (passes internal tests). We just need to...

The benchmark works as far as I can tell (passes internal tests). We just need to put in sese blocks now if that's the case.

... There are things preventing me from doing a precise check.
1) It appears that given the same input and everything, the while loop will inevitably run a different number of times for each run (this occurs in both the original and ported code) and pick a different order of triangles to process.
2) The differences in how we and Java handle collection/sets gives a different ordering of which triangles we process (which affects which triangles become bad at the end).

Aside from that, there seems to be some performance issues.
1) It seems that the original code benefits from branch prediction as successive, duplicate runs (inherent in the benchmark) yields faster and faster timings. Our run-time stays the same in successive runs. This is true even though the number of triangles processed stays relatively close to each other.
2) When processing the large.2 files (about 10k triangles), the difference between our first runtime and the original code's runtime is within 100ms of each other (out of roughly 1000ms), which sounds reasonable (note that on successive runs, the original code speeds up by a factor of 1.6).  However when we process the massive.2 files (roughly 100k triangles), our runtimes are double the original code's runtime (but successive runs of the original code yields a speedup of only 1.12. Whatever speedup it got on the large.2 file is amortized). Also, our ported code garbage collects and then crashes (out of memory) on the second run (there are 3 repeated runs).

This is as much as I can do at the moment, going to need some guidance on the performance issues mentioned above and also where to place the sese blocks.