add GC.safepoint() for compute-bound threads

[JeffBezanson]

This will now sometimes be needed to avoid long-running, non-allocating computations from blocking other threads from running GC. Of course it would be better to have codegen insert gc state transitions, but that is quite fancy and not necessarily free, so we might as well let people work around it manually for now.

[KristofferC]

Ok, but where would you put this call?

[StefanKarpinski]

An example would be pretty helpful here.

[mbauman]

Naive question, and maybe this isn't the place to put this information, but why does the compute thread need to have a safepoint if it's not allocating any objects? If the other threads are allocating then they're hitting safepoints... so if the GC determines it needs to collect on one thread does it block and wait for all other threads to similarly block at safepoints before collecting?

Edit: so would that mean you'd want to structure it in the compute loop to run every N milliseconds, where N is near your maximum acceptable GC latency of the other threads and/or on the same order as the average time-to-safepoint of the other threads?

[JeffBezanson]

if the GC determines it needs to collect on one thread does it block and wait for all other threads to similarly block at safepoints before collecting

Yes.

Running it every N milliseconds would be nice, but pretty fancy. If you can tolerate a bit of slowdown you can just throw it in a loop anywhere. It's only a single load instruction so it's not horribly expensive. I also wouldn't advise using it at all unless the computation takes a really long time.

[mbauman]

Right — I wasn't imaging a timer, but rather giving the docs reader some sort of rule of thumb to allow them to do some reasoning about a rough number of inner loop iterations to run before hitting a safepoint. Of course, you also wouldn't want it in the lowest of loops as it'd break vectorizaton.