search for: safepoint

...joy 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 interested in, the safepoint at the back-edge of a loop might >> look like: >> >> ; <label>: body >> %a = phi i32 [ %a.relocated, %body ] [ %a.initial_value, %pred ] >> %b =...

...gt; <mailto: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 interested in, the safepoint at the back-edge of a loop might > look like: > > ; <label>: body > %a = phi i32 [ %a.relocated, %body ] [ %a.initial_value, %pred ] > %b = phi...

...u, 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 interested in, the safepoint at the back-edge of a loop might > look like: > > ; <label>: body > %a = phi i32 [ %a.relocated, %body ] [ %a.initial_value, %pred ] > %b = phi i32 [ %b.relocated,...

...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, whic...

...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...

...of the "how do we generalize this?" variety. First, let's touch on the attribute. My first concern is naming; I think the use of "statepoint" here is problematic 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 existin...

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 ca...

...#39;d prefer an experimental namespace rather than a webkit namespace. (minor) >>>>>> - Unless I am misreading your proposal, your proposed StackMap intrinsic duplicates existing functionality already in llvm. In particular, much of the StackMap construction seems similar to the Safepoint mechanism used by the in-tree GC support. (See CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you examined these mechanisms to see if you can share implementations? >>>>>> - To my knowledge, there is nothing that prevents an LLVM optimization pass from manufacturing new...

...rs ; to find %obj in the stub I should be able to: - patch ID_OFFSET when I load the description of obj (before the call, when the object is allocated) - use ID_CALL to know which object is the target of the call in order to find the appropriate method. If it could be the case, your patchpoint and safepoint are very interesting for vmkit. We just need a function to retreive, in 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, i...

...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-co...

...these semantics, but if anyone has an alternate approach they'd recommend, I'm open to that too. Here's the semantics of my 'instruction': - It must immediately follow a call instruction, before any return value copies, or frame manipulation. Not every call has a following safepoint. - It has a variable number of arguments (virtual registers). All can be both read and written. - It can handle any combination of stack locations and registers. Ideally, it should not effect register allocation. The approach I've taken to date is based in part on the work done for PATCHPO...

...mespace. (minor) >>>>> - Unless I am misreading your proposal, your proposed StackMap >>>>> intrinsic duplicates existing functionality already in llvm. In >>>>> particular, much of the StackMap construction seems similar to the >>>>> Safepoint mechanism used by the in-tree GC support. (See >>>>> CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp). Have you >>>>> examined these mechanisms to see if you can share implementations? >>>>> - To my knowledge, there is nothing that prevents an LLVM...

The long term plan is a) evolving, and b) dependent on the specific use case. :) It would definitely be nice if we could support both early and late safepoint insertion. I see no reason that LLVM as a project should pick one or the other since 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...

...couple of times over the last few months, we've been working on an approach for supporting precise fully relocating garbage collection in LLVM. I am happy to announce that we now have a version of the code available for public view and discussion. https://github.com/AzulSystems/llvm-late-safepoint-placement <https://github.com/AzulSystems/llvm-late-safepoint-placement> Our goal is to eventually see this merged into the LLVM tree. There's a fair amount of cleanup that needs to happen before that point, but we are actively working towards that eventual goal. Please note that the...

...la 3, dump57 at l(13) 2654: mr 4, 27 2655: bl print_value 2656: ori 4, 21, 7712 2657: li 3, 634 2658: bl trace_bytecode 2659: lis 3, 4031 2660: lwz 3, -12952(3) 2661: cmplwi 0, 3, 1 2662: beq 0, BB10_218 # do_safepoint 2663: BB10_41: # safepointed 2664: cmpw 0, 27, 26 2665: bge 0, BB10_169 # bci_637 2666: BB10_42: # bci_132 2667: lis 21, 3984 2668: ori 4, 21, 6756 2669: li 3, 132 2670: bl trace_bytecode 2671: ori 4, 21, 6556 2...

...thing 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 missed? The problem I'm trying to solve is identifying pointers which might be live at a garbage collection safepoint. This in the context of transforming the IR to insert a statepoint intrinsic to explicitly represent a possible object relocation. We've been using a very straigh forward and, due to implementation simplicity, expensive estimation based on simple reachability*. This suffices for correctn...

...Adapting the new statepoint infrastructure to work with the existing GCMetadataPrinter classes wouldn't be particularly hard. - Are there any GCs out there that need gcroot's single stack slot per value implementation? By default, statepoints may generate a different stackmap for every safepoint in a function. - Is using gcroot and allocas to mark pointers as garbage collected references valuable? (As opposed to using address spaces on the SSA values themselves?) Long term, should we retain the gcroot marker intrinsics at all? Philip Appendix: The Current Implementations Key Classe...

...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 at this step, a collection point (aka safepoint in the GC world) is describe by: * a MCSymbol, which indicates the location of a safepoint (basically the instruction pointer that follows the safepoint) * a list of live roots, each one is described by an offset relative to the frame pointer. Now, I would like to find the concrete address of the...

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 t...

...-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 findCus...