Just curious regarding Slide 16 [1] which indicates UFFI sequence is... 1. Generate bytecodes for marshalling 2. Re-send method invocation Do the bytecodes get cached so that (1.) is only down once? What impact is Sista/Scorch expected to have on UFFI? Considering for example that the commonly used method... ffiCall: fnSpec ^ (self ffiCalloutIn: thisContext sender) convention: self ffiCallingConvention; function: fnSpec module: self ffiLibraryName ...has several message sends. btw, Slide 2 gave me a nice chuckle to start the day. Stabilization is a difficult/boring task with highly visible issues which Esteban bears the brunt of dealing with, along with accompanying pressures. I'd like to take this random opportunity to thank Esteban for his continuing efforts, and also previous Consortium engineers (Igor) and those supporting them. We wouldn't be where we are today without such a focal point. cheers -ben |
we still do not sit to solve the problem, but we have a strategy: SISTA bytecode set contains bytecodes to invoque primitives which means possible to do a primitive call inside a method (it does not needs to be an independent method). This way, the optimiser can work also on methods that ends on primitives. As far as I know, adapting to SISTA will not be very complicated. But of course, there will be some work needed.
thanks :) Esteban
|
Hi Ben, This is the work that Ronie did. You have lower level bytecodes in the SistaV1 bytecode set which can be used for parameters marshalling. Ronie has a prototype where the marshalling of FFI calls is generated image-side once and reused for all calls. For now, if Scorch does not recognise the primitive (and it does not recognise FFI calls), the send is just marked as non inlineable. Hence this works but is not really optimised. Cheers On Tue, Nov 14, 2017 at 11:48 AM, Esteban Lorenzano <[hidden email]> wrote:
Clément Béra Pharo consortium engineer Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq |
Free forum by Nabble | Edit this page |