search for: pr5184

In r85295, in response to the discussion at http://llvm.org/PR5184 (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to non-lazy. It has since come to my attention that this may have been the wrong change, so I wanted to ask you guys. A couple reasons to make the default non-lazy compilation: * The lack of thread-safety surprises new users * C...

Hi Jeffrey, > 2. It could compile C, and either replace B's machine code with a > jump to C, or replace all calls to B with calls to C. Aside from not > having the infrastructure to do this, it's not thread-safe: > http://llvm.org/PR5184. if all calls were via a handle (i.e. load the function pointer out of some memory location then jump to it), then you could compile C, atomically replace the pointer-to-B with the pointer-to-C in the memory location, and later free B using some kind of user-space read-copy-update type logic. Thi...

On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > In r85295, in response to the discussion at http://llvm.org/PR5184 > (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to > non-lazy. It has since come to my attention that this may have been > the wrong change, so I wanted to ask you guys. > > A couple reasons to make the default non-lazy compilation: > * The lack of thread-s...

On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: > >> In r85295, in response to the discussion at http://llvm.org/PR5184 >> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >> non-lazy. It has since come to my attention that this may have been >> the wrong change, so I wanted to ask you guys. >> >> A couple reasons to make the default non-lazy compilation: >&gt...

...ad is still in A, its machine code gets freed, leaving you with a latent crash. 2. It could compile C, and either replace B's machine code with a jump to C, or replace all calls to B with calls to C. Aside from not having the infrastructure to do this, it's not thread-safe: http://llvm.org/PR5184. 3. ??? You'd have an extra option if machine code lifetimes weren't tied to llvm::Function lifetimes, but I haven't spent the time to get that working. Since I didn't have a use for RAUW on a compiled function, I resisted the temptation to guess at the right behavior and put in...

...long familiar with past behavior. In the OSS world, I always favor easing adoption over maintaining the status quo. My meager 2 cents. -Chandler On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > In r85295, in response to the discussion at http://llvm.org/PR5184 > (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to > non-lazy. It has since come to my attention that this may have been > the wrong change, so I wanted to ask you guys. > > A couple reasons to make the default non-lazy compilation: > * The lack of thread-s...

Albert Graef wrote: > The way I do this in Pure is to always call global functions in an > indirect fashion, using an internal global variable which holds the > current function pointer. When a function definition gets updated, the > Pure interpreter just jits the new function, changes the global variable > accordingly, and frees the old code. > > Compared to Duncan's

...>> just design a new JIT. > >>> My meager 2 cents. >>> -Chandler >>> >>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com >>> > wrote: >>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy >>>> to >>>> non-lazy. It has since come to my attention that this may have been >>>> the wrong change, so I wanted to ask you guys. >>>> >>>> A coupl...

http://llvm.org/PR5184 describes two problems with thread-safety in the lazy JIT compiler, the first of which is quite hard to fix if we can fix it at all. Could the people who currently use the lazy compiler speak up either here or on the bug and say what they think the path forward should be? I'm not volunteering t...

...AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Wed, Oct 28, 2009 at 9:50 AM, Chris Lattner <clattner at apple.com> wrote: >> >> On Oct 28, 2009, at 9:41 AM, Jeffrey Yasskin wrote: >> >>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>> non-lazy. It has since come to my attention that this may have been >>> the wrong change, so I wanted to ask you guys. >>> >>> A couple reasons to make the default non-lazy...

...rt using it in new and interesting ways, we should just design a new JIT. >> My meager 2 cents. >> -Chandler >> >> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: >>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>> non-lazy. It has since come to my attention that this may have been >>> the wrong change, so I wanted to ask you guys. >>> >>> A couple reasons to make the default non-lazy...

...cents. >>>>> -Chandler >>>>> >>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> >>>>> wrote: >>>>>> >>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>>> non-lazy. It has since come to my attention that this may have been >>>>>> the wrong change, so I wanted to ask you guys. >>>>>> >>&g...

...to start using it in new and interesting ways, we should just design a new JIT. Evan > > My meager 2 cents. > -Chandler > > On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> In r85295, in response to the discussion at http://llvm.org/PR5184 >> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >> non-lazy. It has since come to my attention that this may have been >> the wrong change, so I wanted to ask you guys. >> >> A couple reasons to make the default non-lazy compilation: >&g...

...;>>> My meager 2 cents. >>>> -Chandler >>>> >>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> >>>> wrote: >>>>> >>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>> non-lazy. It has since come to my attention that this may have been >>>>> the wrong change, so I wanted to ask you guys. >>>>> >>>>> A coup...

...;>> -Chandler >>>>>> >>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> >>>>>> wrote: >>>>>>> >>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>>>> non-lazy. It has since come to my attention that this may have been >>>>>>> the wrong change, so I wanted to ask you guys. >>>>>>...

...>>>>>>> >>>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>>>>> non-lazy. It has since come to my attention that this may have been >>>>>>>> the wrong change, so I wanted to ask you guys. >>>...

...hine code gets freed, leaving you with a latent > crash. > 2. It could compile C, and either replace B's machine code with a > jump to C, or replace all calls to B with calls to C. Aside from not > having the infrastructure to do this, it's not thread-safe: > http://llvm.org/PR5184. > 3. ??? > > You'd have an extra option if machine code lifetimes weren't tied to > llvm::Function lifetimes, but I haven't spent the time to get that > working. > > Since I didn't have a use for RAUW on a compiled function, I resisted > the temptation to g...

...;>>>> >>>>>>> On Wed, Oct 28, 2009 at 9:41 AM, Jeffrey Yasskin <jyasskin at google.com> >>>>>>> wrote: >>>>>>> >>>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy to >>>>>>>> non-lazy. It has since come to my attention that this may have been >>>>>>>> the wrong change, so I wanted to ask you guys. >>>...

...at 9:41 AM, Jeffrey Yasskin >>>>>>>> <jyasskin at google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> In r85295, in response to the discussion at http://llvm.org/PR5184 >>>>>>>>> (Lazy JIT ain't thread-safe), I changed the default JIT from lazy >>>>>>>>> to >>>>>>>>> non-lazy. It has since come to my attention that this may have been >>>>>>>>> the wrong...