search for: lazi

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 * Crashes due to this will be rare

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

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; This argues for better documentation. I'd prefer for EE to abort if user is asking for a known dangerous configuration (multi-threaded and lazy). I think that'd be a decent fix for the thread-safety problem. It'd require an extra check on each call to runJITOnFunctionUnlocked since laziness is set by a call, not on construction. Or, we could use the JIT lock to assert that it's never entered concurrently. On the other hand, Nicolas Geoffray objected when I suggested that in the bug. > The biggest argument I have for staying with lazy is llvm JIT is not a light weight JIT....

>From where I sit, this boils down to a very simple question (modulo Chris's point): Either choice will surprise some users. Which surprise is worse? Personally, I'd always prefer correct but slow behavior by default, and explicitly enabling dangerous (but in some cases fast) behavior. I would also point out that it seems that most of the people new to the JIT are surprised by the

...I'd prefer for EE to abort if >> user is asking for a known dangerous configuration (multi-threaded >> and lazy). > > I think that'd be a decent fix for the thread-safety problem. It'd > require an extra check on each call to runJITOnFunctionUnlocked since > laziness is set by a call, not on construction. Or, we could use the > JIT lock to assert that it's never entered concurrently. On the other > hand, Nicolas Geoffray objected when I suggested that in the bug. > >> The biggest argument I have for staying with lazy is llvm JIT is >...

On Oct 28, 2009, at 10:07 AM, Chandler Carruth wrote: > From where I sit, this boils down to a very simple question (modulo > Chris's point): Either choice will surprise some users. Which surprise > is worse? Personally, I'd always prefer correct but slow behavior by > default, and explicitly enabling dangerous (but in some cases fast) > behavior. The behavior is only

...ort if user >>>> is asking for a known dangerous configuration (multi-threaded and lazy). >>> >>> I think that'd be a decent fix for the thread-safety problem. It'd >>> require an extra check on each call to runJITOnFunctionUnlocked since >>> laziness is set by a call, not on construction. Or, we could use the >>> JIT lock to assert that it's never entered concurrently. On the other >>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>> >>>> The biggest argument I have for stayin...

On Wed, Oct 28, 2009 at 9:57 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

...d prefer for EE to abort if user >>> is asking for a known dangerous configuration (multi-threaded and lazy). >> >> I think that'd be a decent fix for the thread-safety problem. It'd >> require an extra check on each call to runJITOnFunctionUnlocked since >> laziness is set by a call, not on construction. Or, we could use the >> JIT lock to assert that it's never entered concurrently. On the other >> hand, Nicolas Geoffray objected when I suggested that in the bug. >> >>> The biggest argument I have for staying with lazy is ll...

...;>>> is asking for a known dangerous configuration (multi-threaded and lazy). >>>> >>>> I think that'd be a decent fix for the thread-safety problem. It'd >>>> require an extra check on each call to runJITOnFunctionUnlocked since >>>> laziness is set by a call, not on construction. Or, we could use the >>>> JIT lock to assert that it's never entered concurrently. On the other >>>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>>> >>>>> The biggest argument I...

...wn dangerous configuration (multi-threaded and lazy). >>>>>> >>>>> I think that'd be a decent fix for the thread-safety problem. It'd >>>>> require an extra check on each call to runJITOnFunctionUnlocked since >>>>> laziness is set by a call, not on construction. Or, we could use the >>>>> JIT lock to assert that it's never entered concurrently. On the other >>>>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>>>> >>>>>...

...t;>>>> lazy). >>>>>>> >>>>>> >>>>>> I think that'd be a decent fix for the thread-safety problem. It'd >>>>>> require an extra check on each call to runJITOnFunctionUnlocked since >>>>>> laziness is set by a call, not on construction. Or, we could use the >>>>>> JIT lock to assert that it's never entered concurrently. On the other >>>>>> hand, Nicolas Geoffray objected when I suggested that in the bug. >>>>>> >>>>>...

Code that takes the default lazy behavior will still work if the default is changed to non-lazy. The only way non-lazy breaks (as far as I know) is if you've already done some lazy JITting and left some lazy stubs laying around. And code that does that will still work, after adjusting to an API change. This is one of the least disruptive breaking API changes imaginable. And getting rid of

...74_1.diff). I do NOT think we should accept this patch: It changes a lot of APIs and makes users specify the choice in many places, while I think most users really just want one choice for their whole app. There's a good argument to be made that users may want to decide certain calls should be lazily-compiled, but those are boundaries _within_ a transitive call tree, not the whole-tree choice this change allows. I'd be happy with a forced choice when creating the JIT, or with an optional choice defaulted to the safer option, but this patch seems like the wrong thing to do. Evan, you wrot...

On 2009-11-01 08:40, Jeffrey Yasskin wrote: > 2009/10/30 Török Edwin <edwintorok at gmail.com>: > >> On 2009-10-29 23:55, Jeffrey Yasskin wrote: >> >>> On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray >>> <nicolas.geoffray at lip6.fr> wrote: >>> >>> >>>> Hi Jeffrey, >>>> >>>>

On Oct 28, 2009, at 1:10 PM, Renato Golin wrote: > Creating another method (getLazyFunctionPointer) or passing a boolean, > enum, whatever seems like the best course of action right now. > I think that this is a great idea. Instead of making "lazy or not" be a policy maintained by the JIT, why don't we approach this as a bug in the current API. Perhaps we should

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

I recently sent off a fix for lazy vmalloc faults which can happen under = paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a = bit on fixing this. I neglected to notice that since the new call to = flush the MMU update queue is called from the page fault handler, it can = be pre-empted. Both VMI and Xen use per-cpu variables to track lazy = mode state, as all previous

2009/10/28 Chandler Carruth <chandlerc at google.com>: > Surviving new and different uses > *is* the purpose of a good interface. I don't have much to add to this interesting discussion, just like to remind people that changes in the default behaviour are only acceptable (IMHO) when everybody (but a few legacy code) is NOT using (or should not use) the current default behaviour.