search for: safepoints

...epoint(a, b) > ax = *a; > bx = *b; > } > > If so, I would agree with you that this is a correct encoding of object > relocation. I think what got me confused was using the in-tree examples to > reverse engineer the semantics. Both the Erlang and Ocaml examples insert > safepoints after all the LLVM IR passes are run and derived pointers were > inserted. This was the part that got me thinking that the gcroot semantics > were unsuitable for a precise relocating collector. If you completely > ignored these implementations and inserted the full box/safepoint > cal...

...ons *a = ax; *b = bx; safepoint(a, b) ax = *a; bx = *b; } If so, I would agree with you that this is a correct encoding of object relocation. I think what got me confused was using the in-tree examples to reverse engineer the semantics. Both the Erlang and Ocaml examples insert safepoints after all the LLVM IR passes are run and derived pointers were inserted. This was the part that got me thinking that the gcroot semantics were unsuitable for a precise relocating collector. If you completely ignored these implementations and inserted the full box/safepoint call/unbox implemen...

On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects are invalidated at every > safepoint" somehow in the IR itself. So, if %a and %b are values the > GC is

...are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative effect on GC latencies when large amounts of data are copied. To avoid this problem copying large amounts of data can be done in chunks with GC safepoints in between. We'd like to be able to represent such copy using existing instrinsics [1]. For that I'd like to propose a new attribute for llvm.{memcpy|memmove}.element.unordered.atomic calls "requires-statepoint". This attribute on a call will result in a different lowering, which...

...er, and gcroot doesn't capture all >>>> copies of a pointer root which fundamentally breaks collectors >>>> which relocate roots. The only way I know to make gcroot (in its >>>> current form) work reliably for all collectors is to insert >>>> safepoints very early, which has highly negative performance >>>> impacts. There are some (potentially) cheaper but ugly hacks >>>> available if you don't need to relocate roots. >>>> >>>> There's also going to be a follow up post on implementation &...

...atic as this doesn't relate to lowering strategy needed (e.g. statepoints), but the conceptual support (e.g. a safepoint). This could be resolved by simply tweaking to require-safepoint. But that brings us to a broader point. We've chosen to build in the fact intrinsics don't require safepoints. If all we want is for some intrinsics *to* require safepoints, why isn't this simply a tweak to the existing code? callsGCLeafFunction already has a small list of intrinsics which can have safepoints. I think you can completely remove the need for this attribute by a) adding the atomic memc...

I need to be able to detect a well-behaved loop. (i.e one where exp1 assigns a value to an int i, exp2 compares i with a loop constant, exp3 adjusts i by a loop constant, and the inner block has no assignments to i.) I need this because in Sun's Java VM garbage collection only takes place at safepoints, so a potentially unbounded loop must call safepoint() some time. However, safepoints are potentially very costly, so we don't want to have them except where it is absolutely necessary. Any loop that is known to be of finite duration does not need to call safepoint(). I presume that LLVM can...

...plicitly includes both the frame which actually contains the safepoint and any caller frames back to the root of thread. To accomplish this, a stack map is generated at any call site and a stack map is generated for the safepoint itself. > > In LLVM currently, the GCStrategy records "safepoints" which are really points at which stack maps need to be remembered. (i.e. calls and actual stop-the-world safepoints) The GCMetadata mechanism gives a generic way to emit the binary encoding of a stack map in a collector specific way. The current stack maps supported by this mechanism only...

...the caller, from which patchpoint we are coming from (probably by inspecting the stack, we can find the program pointer of the call site and then find the patchpoint descriptor?) * Now, for the GC, if I understand correctly, instead of declaring a variable as a root, you can declare explicitly the safepoints by using patchpoints with something like patchpoint ID_safepoint_17, suspendTheThreadForCollection, list of the alloca (or registers) that contains objects Then in the suspendTheThreadForCollection, we can see that we are coming for the safepoint_17 and then find the locations of the objects? If...

...ncarnation of gcroot, marking an alloca as a gcroot effectively forces a stack spill for that alloca; this means that the relocating collector just updates the single existing pointer on the stack when it does its magic, and you're done. With proper barriers in place, and/or careful location of safepoints by the front-end, it's not that hard to make sure that a relocated pointer gets updated. The real trick, as near as I can tell, would be updating registers that have live roots during a collection. But again based on my past investigations this should just be a matter of ensuring that post-col...

...ive preference to register uses for this instruction. If a virtual register is already in the stack, it shouldn't attempt to reload before this instruction. I haven't been able to find the appropriate hook for this. I can go ahead and hack the folding code to unconditionally fold into SAFEPOINTs and move the load after the SAFEPOINT, but that feels like an utter hack. Before going down the road, does anyone have a better suggestion? I'm very open to suggestions here. If I'm taking the wrong approach or something sounds like it doesn't work the way I've described, plea...

...This explicitly includes both the frame which actually contains the safepoint and any caller frames back to the root of thread. To accomplish this, a stack map is generated at any call site and a stack map is generated for the safepoint itself. In LLVM currently, the GCStrategy records "safepoints" which are really points at which stack maps need to be remembered. (i.e. calls and actual stop-the-world safepoints) The GCMetadata mechanism gives a generic way to emit the binary encoding of a stack map in a collector specific way. The current stack maps supported by this mechanism o...

...ce the infrastructure required is largely overlapping. (Obviously, I'm going to be mostly working on the parts that I need, but others are always welcome to extend in other directions.) One of the challenges we've run into is that supporting deoptimization points (which in practice are safepoints) require a lot of the same infrastructure as early safepoint insertion. It's likely that we'll end with a scheme which inserts safepoint polls quite early (but with restricted semantics and optimization impact) and then converts them to explicit GC safepoints (with full invalidation se...

...wards a CallSite like interface for statepoints, gc_relocates, and gc_results call sites. Is this the right approach? If so, should it live in the IR subtree, or Support? (Note: The current code is only about 40% migrated to the new interface.) * To support invokable calls with safepoints, we need to make the statepoint intrinsic invokable. This is new for intrinsics in LLVM. Is there any reason that InvokeInst must be a subclass of CallInst? (rather than a view over either calls or invokes like CallSite) Would changes to support invokable intrinsics be accepted...

Gordon Henriksen wrote: > On 2008-06-11, at 13:16, Gary Benson wrote: > > Duncan Sands wrote: > > > Can you please attach IR which can be compiled to an executable > > > (and shows the problem). > > > > I've been generating functions using a builder and then compiling > > them with ExecutionEngine::getPointerToFunction(). Is there some > >

Is anyone aware of an existing framework for asking liveness questions about SSA values in the IR? I'm looking for something more precise than the trivial definition provided by SSA itself. I can write something myself (and will if need be), but it seemed like a generic enough problem that I was surprised I couldn't find something already in tree. Anyone know of something I've

...lowering strategy. The concept of such a collector description is very valuable, but the current implementation could use some cleanup. In particular, the custom lowering hooks are a bit of a mess. GCMetadataPrinter - Provides a means to dump a custom binary format describing each functions safepoints. All safepoints in a function must share a single root Value to stack slot mapping. GCModuleInfo/GCFunctionInfo - These contain the metadata which is saved to enable GCMetadataPrinter.

Hi! I have now a more precise question, I hope that this time, someone will be able to help me :) I'm now able to find the gc meta data. To find this data, I simply register a GCMetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that

Hi Chris, Gordon, Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points. I'm not sure who maintains the GC code today in LLVM (I'd be happy to take ownership, if needed). The patch just adds up a custom safepoints flag, similar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as I've tested it on VMKit. So the patch in itself should not be controversial. Chris, I'd like to discuss with you on how we can improve the current GC framework to ta...

...-10-31, at 17:21, Nicolas Geoffray wrote: > Here's a patch to allow a GCStrategy to customize the places where it wants to insert safe points. I'm not sure who maintains the GC code today in LLVM (I'd be happy to take ownership, if needed). > > The patch just adds up a custom safepoints flag, similar to the way the GCStrategy can customize intrinsics lowering, or roots initialization. It works pretty well, as I've tested it on VMKit. So the patch in itself should not be controversial. Seems a perfectly reasonable patch on its own merits. I would be curious what your findCust...