I may have misunderstood the intent of this thread. The jit needs to know which helpers are uninterruptible for several reasons, and it is convenient for it to ask the VM in one place rather than hardcode. So the interface change on both sides is good and commitable ( if tests pass etc. )
However, there is still some triage needed on which helper is uninterruptible and which is not and why. Is that going to happen over time and the interface method will be updated? Thanks, Rana On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Thanks, I will check it today. On 4/17/07, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > Xiao-Feng Li wrote: > > There is a break in Linux64 build. I will commit it after the SVN is ok. > > It should be fixed now in rev 529560. > > > On 4/17/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > >> Let's commit it. > >> > >> On 4/17/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > >> > > >> > On 4/14/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > >> > > On 4/13/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > >> > > > I've attached combined JIT+VM patch to JIRA. The test failed > before > >> > passes > >> > > > now. > >> > > > VM-guru, please check VMEXPORT Boolean > >> > > > vm_helper_is_gc_interruptible(VM_RT_SUPPORT f) method in this > >> patch. > >> > > > >> > > VM gurus, please help checking this method in H3626. Thanks, > xiaofeng > >> > > >> > Mikhail, how would you like to proceed with this patch? Thanks. > >> > > >> > > > On 4/13/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > >> > > > > > >> > > > > 2007/4/13, Mikhail Fursov <[EMAIL PROTECTED]>: > >> > > > > > Rana, > >> > > > > > thank you for the fast update. > >> > > > > > I'll integrate this function usage into JIT and report if the > >> > problem I > >> > > > > have > >> > > > > > disappeares today. > >> > > > > > > >> > > > > > >>BTW, how does the jit knows which helpers throw exceptions? > >> > > > > > JIT generates stack info for every call instruction. So we > can > >> > > > > > unwind stack frame from every call. > >> > > > > > Actually this is not enough: JIT must generate stackinfo for > >> every > >> > push > >> > > > > inst > >> > > > > > also to handle SOE correctly. But this is one of the TODO > list > >> > items. > >> > > > > > > >> > > > > > > >> > > > > > Another problem with helper calls I know is their calling > >> > conventions. > >> > > > > > Now the calling convention of every helper is hardcoded to > JIT. > >> > > > > > I think it worth creating another JIRA to solve the problem > one > >> > day. > >> > > > > Today I > >> > > > > > know no bugs about it, so it's design only issue. > >> > > > > > >> > > > > There is one already: HARMONY-2702. Actually Jitrino provides > >> such > >> > > > > interface internally, > >> > > > > CompilationInterface::getRuntimeHelperCallingConvention(), so > fix > >> > > > > should be easy enough (yet is blocked by HARMONY-3553). > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > On 4/13/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > >> > > > > > > > >> > > > > > > Yes, that make sense. I'll wait a bit to see if Mikhail > >> has any > >> > more > >> > > > > > > suggestions and change it to is_gc_interruptible. > >> > > > > > > > >> > > > > > > On 4/12/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > >> > > > > > > > Agree that this information better be provided by VM > >> than JIT > >> > > > > internals. > >> > > > > > > > > >> > > > > > > > Rana, Thanks for the quick work. A minor comment: > >> > > > > > > > > >> > > > > > > > The interface name might be better use > >> "has_gc_safepoint" or > >> > > > > > > > "is_gc_interruptible" than "is_suspension_point", since > the > >> > helper > >> > > > > is > >> > > > > > > > a function (not a point), and "suspension" is > >> implementation > >> > detail. > >> > > > > > > > > >> > > > > > > > Thanks, > >> > > > > > > > xiaofeng > >> > > > > > > > > >> > > > > > > > On 4/13/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > >> > > > > > > > > Mikhail, > >> > > > > > > > > I extended the vm-jit interface with a function: > >> > > > > > > > > boolean vm_is_helper_suspension_point( VM_RT_SUPPORT f) > >> > > > > > > > > > >> > > > > > > > > and attached it to your JIRA. > >> > > > > > > > > > >> > > > > > > > > Right now it returns true for almost every helper. > >> But you > >> > may > >> > > > > want > >> > > > > > > > > to update this instead of hardcoding in the jit. At > some > >> > point, we > >> > > > > > > > > need some analysis to determine which helpers are > >> > interruptible. > >> > > > > > > > > > >> > > > > > > > > BTW, how does the jit knows which helpers throw > >> > exceptions? > >> > > > > > > > > > >> > > > > > > > > Rana > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > On 4/11/07, Mikhail Fursov <[EMAIL PROTECTED]> > wrote: > >> > > > > > > > > > On 4/12/07, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > >> > > > > > > > > > > > >> > > > > > > > > > > On 4/11/07, Xiao-Feng Li <[EMAIL PROTECTED]> > >> wrote: > >> > > > > > > > > > > > On 4/12/07, Rana Dasgupta <[EMAIL PROTECTED]> > >> wrote: > >> > > > > > > > > > > > > A silly question possibly. But other than > inlined > >> > > > > fastpaths, > >> > > > > > > why not > >> > > > > > > > > > > > > gcm treat all helper calls as interruptible? > >> > > > > > > > > > > > > >> > > > > > > > > > > > I think this needs case by case study to decide > >> which > >> > ones > >> > > > > can > >> > > > > > > be > >> > > > > > > > > > > > interruptible. In most cases, the helper is only > an > >> > > > > extension of > >> > > > > > > a > >> > > > > > > > > > > > certain bytecode operation, which can be > virtually > >> > treated > >> > > > > as a > >> > > > > > > > > > > > bytecode (or part of a bytecode semantics). > >> Normally, > >> > the > >> > > > > > > safepoint > >> > > > > > > > > > > > can be before or after it, but not in middle of > >> it. If > >> > we > >> > > > > think > >> > > > > > > of the > >> > > > > > > > > > > > stack map info, the helper itself may not stand > >> for a > >> > formal > >> > > > > > > method > >> > > > > > > > > > > > frame for GC or exception handling. > >> > > > > > > > > > > > >> > > > > > > > > > > This is a good way to look at helper calls. My > point, > >> > > > > > > however, was > >> > > > > > > > > > > not really that helper calls should be > interruptible. > >> > But that > >> > > > > > > other > >> > > > > > > > > > > than the fastpath for which the JIT sees the IR, > >> why not > >> > treat > >> > > > > the > >> > > > > > > > > > > calls themselves as ineligible for code motion > >> etc. like > >> > other > >> > > > > > > > > > > operators with side effects? Is the cost too high? > >> > > > > > > > > > > Implementing the interface extension is not hard > >> for the > >> > VM, > >> > > > > but > >> > > > > > > looks > >> > > > > > > > > > > like implementation dependant info passed from the > >> VM to > >> > the > >> > > > > JIT. > >> > > > > > > > > > > > >> > > > > > > > > > > Here is more details: > >> > > > > > > > > > The example of a helper that can be moved by GCM are > >> > number > >> > > > > > > conversion helpers. > >> > > > > > > > > > 'i2d' never throws exceptions and this knowledge is > >> > hardcoded in > >> > > > > > > HLO. On the > >> > > > > > > > > > other hand this HIR opcode is translated into LIR > >> > vm-helper > >> > > > > call, so > >> > > > > > > instead > >> > > > > > > > > > of simple Java opcode it becomes a > >> > > > > > > > > > call. I can hardcode which vm-helper call is > >> interruptable > >> > and > >> > > > > which > >> > > > > > > is > >> > > > > > > > > > not on the > >> > > > > > > > > > JIT side, but think retrieving this information from > >> VM is > >> > a > >> > > > > better > >> > > > > > > solution. > >> > > > > > > > > > Another example of uninterruptable vm-helper is > >> > > > > > > > > > TLS accessor. This helper is placed into the middle > >> of the > >> > > > > inlined > >> > > > > > > > > > 'alloc' helper body because 'alloc' reqires TLS > access. > >> > > > > > > > > > Now managed<->unmanaged convertion checker in GCMap > >> pass > >> > has > >> > > > > > > hardcoded > >> > > > > > > > > > knowledge that TLS access will never be suspended. > >> > > > > > > > > > > >> > > > > > > > > > JET compiler uses different code then OPT and > maintains > >> > special > >> > > > > > > > > > GC-bitmasks for object operands runtime. > >> > > > > > > > > > The per-call gc-mask maintainance is not free and > >> can also > >> > be > >> > > > > > > > > > optimized if VM provides a method to describe which > >> call > >> > is real > >> > > > > > > > > > suspension point and which is not. > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > + Suspension and exception throwing are different > >> > attributes. > >> > > > > SOE > >> > > > > > > can be > >> > > > > > > > > > thrown even if method is not a suspension point. So > JIT > >> > must > >> > > > > prepare > >> > > > > > > stack > >> > > > > > > > > > info for every call it generates to be able to > >> unwind the > >> > > > > frame. > >> > > > > > > > > > > >> > > > > > > > > > -- > >> > > > > > > > > > Mikhail Fursov > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > -- > >> > > > > > > > http://xiao-feng.blogspot.com > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > -- > >> > > > > > Mikhail Fursov > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Mikhail Fursov > >> > > > > >> > > > >> > > > >> > > -- > >> > > http://xiao-feng.blogspot.com > >> > > > >> > > >> > > >> > -- > >> > http://xiao-feng.blogspot.com > >> > > >> > >> > >> > >> -- > >> Mikhail Fursov > >> > > > > > > > -- > Gregory > > -- Mikhail Fursov
