search for: lazying

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:

On Wed, Oct 28, 2009 at 12:21 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > 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

>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

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 objection is simple.

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

I have no objection to Chris' proposal. Evan On Oct 29, 2009, at 9:45 AM, Jeffrey Yasskin wrote: > Are you objecting to Chris's proposal? I was waiting to implement it > until you replied so I wouldn't have to implement two things. 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 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

Are you objecting to Chris's proposal? I was waiting to implement it until you replied so I wouldn't have to implement two things. 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

Cool, I'll start implementing it. Thanks all for the decision! On Thu, Oct 29, 2009 at 11:03 AM, Evan Cheng <evan.cheng at apple.com> wrote: > I have no objection to Chris' proposal. > > Evan > > On Oct 29, 2009, at 9:45 AM, Jeffrey Yasskin wrote: > >> Are you objecting to Chris's proposal? I was waiting to implement it >> until you replied so I

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

On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > 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 >

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

A possible patch implementing this is at http://codereview.appspot.com/144074 (http://codereview.appspot.com/download/issue144074_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

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.