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
