Hi all,
I will not have time for another couple of weeks for the JIT but just in case someone is interested to continue or has some insight here is a list of known issues: 1.) The Delay test is failing as the spOffset/sp of a context is -1. This means that in some jitted code there is an unbalanced push/pop in the stack. 2.) The maybe releasing of native code is failing with snapshot/resume of the image. Passing an '-i' will 'fix' the segfault. The interesting bit is that this happens _after_ the fixup must have set context native_ip to 0. So I wonder if this could actually be the fix: diff --git a/libgst/interp-jit.inl b/libgst/interp-jit.inl index 0e8fa27..18dc40e 100644 --- a/libgst/interp-jit.inl +++ b/libgst/interp-jit.inl @@ -353,6 +353,7 @@ refresh_native_ips (OOP contextOOP) virtualIP = TO_INT (context->ipOffset); native_ip = _gst_map_virtual_ip (context->method, receiverClass, virtualIP); + context->method->flags |= F_XLAT_REACHABLE; #ifndef OPTIMIZE if (!native_ip) 3.) The debug semaphore does not work, I think it should either set the exception flag or the emit_interrupt_check should make a NULL test for it. I am not sure how this is supposed to work yet. 4.) Porting to GNU lighting 1.9/2.0 would be nice. This way I could have a JIT on ARM as well. I have had this wish/hope for quite some time already but thanks to another Paulo GNU lightning can support that now. cheers holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, Jun 09, 2013 at 09:18:00PM +0200, Holger Hans Peter Freyther wrote:
> Hi all, > > I will not have time for another couple of weeks for the JIT but just > in case someone is interested to continue or has some insight here is > a list of known issues: > > > 1.) The Delay test is failing as the spOffset/sp of a context is -1. > This means that in some jitted code there is an unbalanced push/pop > in the stack. The issue is not the spOffset -1 for the context part but actually the inlined primitive for Object>>#basicAt:. I have #ifdef 0/#endif out the code to force to go through the normal primitive code and the test is passing now. I fail to create such a BlockContext (I assume it is going through the Process>>#queueInterrupt or signalInterrupt:). Paolo do you think you could help me to build a shorter re-producer? Would you mind if we disable the inlining with #ifdef 0 right now and re-enable with some more time? Even on the interpreter: An instance of BlockContext parent: BlockClosure>>ensure: (BlkClosure.st:271) nativeIP: 0 ip: 8 sp: -1 receiver: UndefinedObject method: [] in UndefinedObject>>executeStatements outerContext: nil [] in BlockClosure>>asContext: (BlkClosure.st:181) BlockContext class>>fromClosure:parent: (BlkContext.st:68) optimized [] in UndefinedObject>>executeStatements (tests/delays.st:40) BlockClosure>>ensure: (BlkClosure.st:271) [] in Delay>>value:onTimeoutDo: (Delay.st:315) BlockClosure>>on:do: (BlkClosure.st:196) Delay>>value:onTimeoutDo: (Delay.st:316) UndefinedObject>>executeStatements (tests/delays.st:40) _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
On Sun, Jun 16, 2013 at 08:27:25AM +0200, Holger Hans Peter Freyther wrote:
> On Sun, Jun 09, 2013 at 09:18:00PM +0200, Holger Hans Peter Freyther wrote: > Even on the interpreter: > An instance of BlockContext > parent: BlockClosure>>ensure: (BlkClosure.st:271) > nativeIP: 0 > ip: 8 > sp: -1 > receiver: UndefinedObject > method: [] in UndefinedObject>>executeStatements > outerContext: nil It is really a "wonder" that this is working at all... VMpr_Object_basicAt int arg2 = -1; index_oop(oop1, arg2); index_oop(oop, 4294967295) object = OOP_TO_OBJ(oop); intptr_t instanceSpec = GET_IN.. return index_oop_spec(oop, object, index, instanceSpec); index_oop_spec(oop, object, 4294967295, 57407) if (4294967295 < 1) return NULL index = 4294967295 - 1; ... case GST_ISP_POINTER: maxIndex = 15; index += instanceSpec >> ISP_NUMFIXEDFIELDS (5) return object->data[5] ... Is this signed => unsigned conversion wanted or is it just some luck that this is working out okay? holger _______________________________________________ help-smalltalk mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/help-smalltalk |
Free forum by Nabble | Edit this page |