search for: gc'd

On 30 Dec 2012, at 01:54, Talin wrote: > I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been two objections to this approach: first, the overhead that would be added to the Pointer type - the vast majority of LLVM users don't want to have to pay an extra 4-8 bytes per Pointer type. An...

On Sun, Dec 30, 2012 at 2:17 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 30 Dec 2012, at 01:54, Talin wrote: > > > I completely agree with your point about wanting to be able to attach GC > metadata to a type (rather than attaching it to a value, as is done now). > In the past, there have been two objections to this approach: first, the > overhead that would be added to the Pointer type - the vast majority of > LLVM users don't want to have to pay an extra 4-8 bytes...

First of all, thanks for looking into this! As you've no doubt discovered, I'm one of the people who has talked a lot about this issue in the past, and have been frustrated with the lack of progress in this area. I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been two objections to this approach: first, the overhead that would be added to the Pointer type - the vast majority of LLVM users don't want to have to pay an extra 4-8 bytes per Pointer type. An...

...ack moves to a non-zero address space. These would be relatively easy to extract, and if it’s an approach that would be useful then I could probably post them for review this week. Having allocas in two address spaces seems plausible if they’re conceptually on different stacks, but using them for GC’d allocations seems odd, as you’d need to ensure that they were copied if live at the end of the stack frame, effectively turning the model into a collection of garbage collected activation records, rather than a stack. For this use, I suspect that you’d need something more like a gc-alloca instru...

So there have been several recent discussions about the issues around DWARF-agnostic linking and gc-sections, linkonce function definitions being dropped, etc - and just how much DWARF-awareness would be suitable in a linker to help with this situation. I'd like to discuss a narrower instance of this issue: Zero length gc'd/deduplicated functions. LLVM seems to at least produce zero len...

...t transform its output into SSA form: GHC must reify its stack. It would be nice (both for GHC and for llgo) if LLVM could be made to treat the stack pointer as a volatile register that may be changed by any function call.  In this model, the stack pointer needs to be treated the same as any other GC’d object — stack maps need to be emitted for it, and the RTS is allowed to relocate it. Would this be practical?  If so, it would be a major boon to the implementation of lightweight threading in languages that compile to LLVM IR. Sincerely, Demi Obenour -------------- next part -------------- A...

...having the flag to switch back when users find surprise places that can't handle the new behavior). In long: https://reviews.llvm.org/D81784 and follow-on patches modified the behavior of lld with regards to resolving relocations from debug sections to dead code (either comdat deduplicated, or gc-sections use). A very quick summary of the situation: Original Behavior: - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 elsewhere - gold/lld: 0+addend everywhere Limitations/bugs: - bfd/gold/lld - doesn't support 0 as a valid executable address with...

...lic* *static* *void* main(String[] args) *throws* Exception { > > LibvirtCrashTest testInstance = *new* LibvirtCrashTest(); > > > *for*(*int* counter = 0; counter < 3; counter++) { > > testInstance.createAndDestroyDefaultAuthConnection(); > > System.*out*.println("gc'ing"); > > System.*gc*(); > > System.*out*.println("gc'd"); > > *int* tCounter = 0; > > *while*(tCounter++ < 20) { > > System.*out*.println("waiting.. " + tCounter); > > Thread.*sleep*(1000); > > } > > } > > S...

I'm working on an LLVM backend for Idris, a garbage-collected pure functional programming language, and have experienced some frustration that LLVM's GC support, specifically with regard to mapping roots, operates only on allocas. This entails a lot of otherwise unnecessary stack allocation (especially in a pure language, where in-place mutation is rare) and imposes limitations on what optimizations can be applied. Other LLVM users have used elabor...

...access >> variables on >> the frame but also pass in a static link. > > > Ok. Are you planning on garbage collecting your stack frames, or do > you just need a static link? If you just need a static link (because > of nested functions like pascal) but don't need GC'd stack frames, > there is no need even for tail call support and CPS and other > craziness, just pass your static link or display as an argument: lower > to LLVM just like you would lower to machine code. In order to return closures (which are functions, but may have some depend...

...losures, I need to be able to not only access variables on > the frame but also pass in a static link. Ok. Are you planning on garbage collecting your stack frames, or do you just need a static link? If you just need a static link (because of nested functions like pascal) but don't need GC'd stack frames, there is no need even for tail call support and CPS and other craziness, just pass your static link or display as an argument: lower to LLVM just like you would lower to machine code. > As far as I can tell from reading the notes on the topic, the static link could > b...

...the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html ) to be quite amusing. First, this article should be titled "the case against C / LLVM 2.5", not against LLVM in general. There is nothing in the design that prevents holding GC roots in registers, it is just that noone has implemented support for it yet. It would actually be a pretty simple hack to move the current GC implementation to use the address space support, and say that all pointers into address space 42 are GC'd pointers (for example). This would w...

I was wondering what the current state of this (explicitly managed stack frames) is. Is it being worked on? If not, how hard do you think it would be for me to add it? I am more than willing to work on it, but don't have any experience with LLVM, so it might take a while. The reason I ask is because I am starting work on a project to make a language similar to ML with which to experiment,

...*static* *void* main(String[] args) *throws* Exception { > > LibvirtCrashTest testInstance = *new* LibvirtCrashTest(); > > > *for*(*int* counter = 0; counter < 3; counter++) { > > testInstance.createAndDestroyDefaultAuthConnection(); > > System.*out*.println("gc'ing"); > > System.*gc*(); > > System.*out*.println("gc'd"); > > *int* tCounter = 0; > > *while*(tCounter++ < 20) { > > System.*out*.println("waiting.. " + tCounter); > > Thread.*sleep*(1000); > > } > > } &gt...

...y understanding LLVM better. Some more comments below: Chris Lattner wrote: >>Couldn't the front-end just produce stores/volatile stores and then a >>compilation pass transform them into a write-barrier if necessary? > > > Sortof. The problem with this is that (without gcwrite) there is no way > to identify the stores that should be turned into write barriers. In > particular, the heap may have multiple parts to it, some of which are GC'd > and some are not. For example, the .NET framework has different pointer > types for managed and unmanaged poi...

There are two C++ signatures for CreateConstGEP1_32: Value * CreateConstGEP1_32 (Value *Ptr, unsigned Idx0, const Twine &Name="") Value * CreateConstGEP1_32 (Type *Ty, Value *Ptr, unsigned Idx0, const Twine &Name="") I'm assuming that this means that the caller can supply the expected type, and get error checking or casting? Or choose to not supply the

...nd a -1/-1 pair have a reserved meaning in that section. If you're looking only at zero-length functions, you can stop there; but I'm not sure why stopping there solves much of a real problem, as zero-length functions seem like a weird corner case. Linkers know how to strip dead functions (gc) or deduplicate them (icf, COMDAT) and people do this all the time, in some cases (COMDAT) without explicitly asking for it, so non-zero-length functions seem like the much more interesting case. In that situation, -1 (or -2) seems like a much wiser choice of blessed-as-not-real address, versus 0x...

...llowing is some known issue? > > > > While performing the following simple test, I see my JVM crashing > > (consistently): > > 1. Open a connection to an ESXi driver/host (passing ConnectAuthDefault > > instance). > > 2. Close the connection. > > 3. Invoke GC > > > > When GC is triggered, at some point, some unallocated native memory is > > being tried to release. That's failing. > > > > The error thrown is: > > > > java(78745,0x70000241e000) malloc: *** error for object 0x7fd5df561390: > > pointer...

...t; >> > >> >> >In long: >> >> >https://reviews.llvm.org/D81784 and follow-on patches modified the behavior >> >> >of lld with regards to resolving relocations from debug sections to dead >> >> >code (either comdat deduplicated, or gc-sections use). >> >> > >> >> >A very quick summary of the situation: >> >> > >> >> >Original Behavior: >> >> > >> >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >> >> &gt...

...t can't handle the new behavior). >> > >> >In long: >> > https://reviews.llvm.org/D81784 and follow-on patches modified the behavior >> >of lld with regards to resolving relocations from debug sections to dead >> >code (either comdat deduplicated, or gc-sections use). >> > >> >A very quick summary of the situation: >> > >> >Original Behavior: >> > >> > - bfd: 1 for debug_ranges(0 would prematurely terminate the list), 0 >> > elsewhere >> > - gold/lld: 0+addend everywhere >&...