search for: lazy

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

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: >> * The lack of...

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

...who run into this problem don't think they're doing anything unusual, and in fact their code works fine with the eager JIT. People shouldn't stumble into broken behavior, and defaults are good to prevent stumbling. To avoid misconceptions, Unladen Swallow added the line to turn off the lazy jit months ago, and we'll keep that line whatever the decision is here. We might take advantage of a thread-safe code-patching facility eventually, but we've been designing assuming nobody else will implement that for us. I favor changing the default because it'll help newbies, not beca...

...9;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 current behavior, where as those who would be surprised by needing to enable lazy JIT are those 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 ht...

There is nothing here that prevents users from enabling or disabling lazy JIT. We're talk about flipping the default behavior. That does not make the API any better or worse. Nor does it fix the inherent thread safety issue. I can tell you there are no Apple clients that depend on the lazy JIT. Please do not imply I am being secretive. I am simply busy. My o...

...) > behavior. The behavior is only dangerous because people are using it in new and different ways. > > I would also point out that it seems that most of the people new to > the JIT are surprised by the current behavior, where as those who > would be surprised by needing to enable lazy JIT are those long > familiar with past behavior. In the OSS world, I always favor easing > adoption over maintaining the status quo. 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). The big...

...th a lot of what you wrote below, but it's not worth > arguing about if there's a compromise we can both live with. > > On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng <evan.cheng at apple.com> wrote: >> There is nothing here that prevents users from enabling or disabling lazy >> JIT. We're talk about flipping the default behavior. That does not make the >> API any better or worse. Nor does it fix the inherent thread safety issue. >> >> I can tell you there are no Apple clients that depend on the lazy JIT. >> Please do not imply I am be...

...<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 compilation: >&g...

...ings. I disagree with a lot of what you wrote below, but it's not worth arguing about if there's a compromise we can both live with. On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng <evan.cheng at apple.com> wrote: > There is nothing here that prevents users from enabling or disabling lazy > JIT. We're talk about flipping the default behavior. That does not make the > API any better or worse. Nor does it fix the inherent thread safety issue. > > I can tell you there are no Apple clients that depend on the lazy JIT. > Please do not imply I am being secretive. I am s...

...t you wrote below, but it's not worth >> arguing about if there's a compromise we can both live with. >> >> On Thu, Oct 29, 2009 at 12:36 AM, Evan Cheng <evan.cheng at apple.com> wrote: >>> There is nothing here that prevents users from enabling or disabling lazy >>> JIT. We're talk about flipping the default behavior. That does not make the >>> API any better or worse. Nor does it fix the inherent thread safety issue. >>> >>> I can tell you there are no Apple clients that depend on the lazy JIT. >>> Please d...

Hi Jeffrey, Jeffrey Yasskin wrote: > Cool, I'll start implementing it. > Great! Thanks. Just to clarify things: on my end, it doesn't really matter what is the default behavior, as long as vmkit can continue to have the existing behavior of lazy compilation. With Chris' solution, I was wondering how you would implement the getPointerToFunction{Eager, Lazy} functions when the getPointerToFunction is called by the JIT, not the user. For example, when Function F calls Function G and the JIT needs an address for G (either a callback or...

...> > Jeffrey Yasskin wrote: >> >> Cool, I'll start implementing it. >> > > Great! Thanks. > > Just to clarify things: on my end, it doesn't really matter what is the > default behavior, as long as vmkit can continue to have the existing > behavior of lazy compilation. With Chris' solution, I was wondering how you > would implement the getPointerToFunction{Eager, Lazy} functions when the > getPointerToFunction is called by the JIT, not the user. For example, when > Function F calls Function G and the JIT needs an address for G (either a...

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

...e defaulted to the safer option, but this patch seems like the wrong thing to do. Evan, you wrote, "there are existing customers out there that are using previous llvm release who will not appreciate the API change." Who are they? Recall that after my original change they can get back to lazy compilation by adding jit->DisableLazyCompilation(false) to their code. They have no need for #ifdefs. I still think that having a default that's right in nearly all cases is the best option (the only concrete counter-example I've seen is lli), but I'm happy to write another patch...

...t;>> >>>>> >>>> Great! Thanks. >>>> >>>> Just to clarify things: on my end, it doesn't really matter what is the >>>> default behavior, as long as vmkit can continue to have the existing >>>> behavior of lazy compilation. With Chris' solution, I was wondering how you >>>> would implement the getPointerToFunction{Eager, Lazy} functions when the >>>> getPointerToFunction is called by the JIT, not the user. For example, when >>>> Function F calls Function G and the J...

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

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

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

...good point when not to change the default even when it's dangerous) is the strcpy() in the libc. It's dangerous, malicious, bearing stupid, but still there. You have the strncpy (and all associated variants) but it's not compulsory nor the default behaviour. Creating another method (getLazyFunctionPointer) or passing a boolean, enum, whatever seems like the best course of action right now. I understand that passing lots of Function*s to the JIT and only generating what's really executed would be "nice" but (as was pointed out before) this is signal of bad code. You shou...