Menu
▾
▴
Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers
|
From: Stefan R. <Ste...@gm...> - 2016-05-17 00:52:52
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>>So, the (possible) copy-back semantics of Get<PrimitiveType>ArrayElements effectively make a direct buffer copy of the contents</div> <div> </div> <div>Except that a direct buffer instantanously reflects modifications on Java-side</div> <div> </div> <div>>If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem.</div> <div> </div> <div>Good point: A single threaded evironment would (usually) not notice the difference between direct or copy-back semantics. Given that JyNI holds a native GIL and native extensions are usually designed in context of a GIL'ed environment chances are good that we would get away with the copy-back fallback for writable PyBuffer in the majority of cases.</div> <div><br/> Still, note that also even a single threaded setup could break this:<br/> The thread could create two (or more) PyBuffer-views of the same object and hand both to various functions that read and write on them without calling release (and thus trigger copy-back) inbetween. The extension would expect if view 'A' was modified, view 'B' already reflects this modification when passed to another function. One could argue this is an insane design, but I actually cannot assess what good reasons some programmer might have for this.</div> <div><br/> > The only way I can imagine an object with Java fields as storage giving you a direct ByteBuffer on demand is to allocate one and copy its state there. [...] effectively a change of implementation on the fly.</div> <div> </div> <div>This is what I have in mind. Changing the backend on the fly shouldn't be much more expensive than creating a copy, but would then save the cost of copy-back and entire copy cost for future calls. Using the bulk-set method of ByteBuffer this should be easy and efficient to do (bulk-get to convert the other direction). The only infeasible situation would be if an AS_DIRECT_NIO buffer was requested while an array-backed buffer is exported and not yet released or vise versa. In this case the request should just fail. I suppose for sake of debugging we should add a verbose mode/flag that makes Jython print out (or append it to the error message in bufferErrorFromSyndrome) the exact reason why some buffer-request failed so a user is able to identify the design flaw.</div> <div> </div> <div>> This seems to bring us full circle to the behaviour of Get<PrimitiveType>ArrayElements, except that I suppose the object knows it has done it and can handle intervening access via the Java API</div> <div> </div> <div>Since actual views to the same memory would be shared with (native) extensions unlike Get<PrimitiveType>ArrayElements (in copy-case/no array pinning) this would not break the case described above, where multiple PyBuffer views to the same object are in the game.</div> <div> </div> <div>I'm not sure what you mean by "full circle to the behaviour of Get<PrimitiveType>ArrayElements", so let me comprehend how I assume the fallback (in BaseBuffer etc) for non-array-backed ByteBuffer backend would take place:<br/> (gave it some thoughts recently)</div> <div> </div> <div>- use bulk-get to copy buffer content to a temporary array (maybe a reused one, but that's an optimization; also it might often be sufficient to copy a limited subsection of the buffer, which is another optimization)<br/> - perform on the temporary array just like one would usually do on the backing array<br/> - use bulk-set to copy-back the temporary array to the buffer<br/> - these operations should be glued together by a synchronized block (on the ByteBuffer backend) in order to appear like an atomical operation<br/> (this could actually still interfere with native buffer-access in multi-threaded case, but multiple threads writing to the same buffer would not end-up sanely anyway. (ByteBuffer does not prihibit this (e.g. by ConcurrentModificationException) does it?)<br/> (obviously the bulk-get can be skipped for write-only access and the bulk-set can be skipped for read-only access etc)</div> <div><br/> This would be somehow "full circle to the behaviour of Get<PrimitiveType>ArrayElements" but would move the copy-back issue to Java-side, which is good: On Java-side we have much better control of copy-back timing and corresponding thread synchronization, unlike inside a foreign C-extension. Also, Java-code would be aware of this semantics or use the AS_ARRAY flag, both of which would be fine.</div> <div> </div> <div> <div> </div> <div> </div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Montag, 16. Mai 2016 um 22:04 Uhr<br/> <b>Von:</b> "Jeff Allen" <ja...@fa...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...><br/> <b>Cc:</b> "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Thanks for that. So, the (possible) copy-back semantics of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> effectively make a direct buffer copy of the contents. If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem. But it is not difficult to cook up a scenario where another thread or call-back into Java sees a different state from C.</p> <p>Alternatively, one uses the "critical" methods, and suffers restrictions that are, I expect, unenforcible on arbitrary CPython extension modules, such as being short and not yielding the CPU.</p> <p>I'm reminded of the relationship in CPython between C-code and interpreted code, where the GIL must be held, proving all other threads are "restubg" between instructions, and a context switch is only allowed when surrounded by the appropriate magical incantations. I think the Universe is trying to tell us something.</p> <p>The problem I see with the <tt>DIRECT_NIO</tt> flag is that one cannot expect to choose, at the point of getting a PyBuffer, whether that buffer should be direct or heap. The data that hold the state of an object have a certain implementation in Java, and so the buffer will be a heap buffer. Or one can imagine a <tt>PyObject</tt> whose state is always in a direct <tt>ByteBuffer</tt> (representing an image mapped from disk, say) and then the <tt>PyBuffer</tt> would always be direct. Just possibly objects whose main purpose is to be native-friendly would have that implementation. Just possibly, this is a thing you get to choose when the object is constructed.</p> <p>The only way I can imagine an object with Java fields as storage giving you a direct <tt>ByteBuffer</tt> on demand is to allocate one and copy its state there. This seems to bring us full circle to the behaviour of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> , except that I suppose the object knows it has done it and can handle intervening access via the Java API ... effectively a change of implementation on the fly.</p> <pre class="moz-signature">Jeff Allen</pre> <div class="moz-cite-prefix">On 15/05/2016 16:39, Stefan Richthofer wrote:</div> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>Just an add-on to my recent post:</div> <div> </div> <div>>It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</div> <div> </div> <div>I think it is likely the JVM does not offer a backing array, if the buffer is created as direct (i.e. these flags likely exclude each other), because this would imply array pinning and all the restrictions coming with it. I didn't test it though, but anyway we cannot rely on the one or other behavior, as doc explicitly does not guarantee a backing array for direct buffers, saying this is "implementation specific".</div> <div> </div> <div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Sonntag, 15. Mai 2016 um 11:57 Uhr<br/> <b>Von:</b> "Jeff Allen" <a class="moz-txt-link-rfc2396E"><ja...@fa...></a><br/> <b>An:</b> "Stefan Richthofer" <a class="moz-txt-link-rfc2396E"><Ste...@gm...></a>, "Jython Developers" <a class="moz-txt-link-rfc2396E"><jyt...@li...></a><br/> <b>Betreff:</b> [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Stefan:</p> <p><a class="moz-txt-link-freetext" href="https://github.com/jythontools/jython/pull/39" target="_blank">https://github.com/jythontools/jython/pull/39</a></p> <p>What difference does it make in your use case whether a NIO ByteBuffer is direct or non-direct? I can see why a client might want to know which it had been given, but not why it might want an exception raised in one or other case.</p> <p>Nothing I'm doing seems to depend on what kind of memory the exporting object has, therefore on the implementation type of <tt>ByteBuffer storage</tt>. It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</p> Jeff <pre class="moz-signature">-- Jeff Allen</pre> ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! <a class="moz-txt-link-freetext" href="https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________" target="_blank">https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________</a> Jython-dev mailing list <a class="moz-txt-link-abbreviated">Jyt...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a></div> </div> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </div></div></body></html> |
