[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: For clarification, the incident I referred to is entirely unrelated to *this* issue: Of course Dino Viehland has been rational, friendly and competent. I wanted to point out that people might have had a formative experience *elsewhere*. --

[issue36839] Support the buffer protocol in code objects

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: FWI, I wrote my idea in python-ideas mailing list. https://mail.python.org/archives/list/python-id...@python.org/message/VKBXY7KDI2OGESB7IPAMAIIHKR4TC7TQ/ -- ___ Python tracker

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: Though code objects do not concern me directly, as the author of memoryview I now concur with Inada-san that we should not support hacks in the Python code base that benefit a single company. -- ___ Python tracker

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: After seeing people from a certain company defend a bizarre and broken stack with falsehoods, I apologize to Inada-san and now assume that he had a similar experience. -- nosy: +skrah ___ Python tracker

[issue36839] Support the buffer protocol in code objects

Brett Cannon added the comment: "I'm sorry, I thought "fantasy" was good metaphor." No problem! Saying something is "fantasy" like "it's based on fantasy" -- in North America at least -- is like saying "you're fooling yourself" or "you're delusional". --

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: I'm sorry, I thought "fantasy" was good metaphor. I just meant "the estimation seems too optimistic and rough. discussion should not based on it". -- ___ Python tracker

[issue36839] Support the buffer protocol in code objects

Brett Cannon added the comment: Let's please keep this respectful. Saying people are basing things "on fantasy" or that "people need to develop reading skills" is not helpful. -- ___ Python tracker

[issue36839] Support the buffer protocol in code objects

Change by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: There's no point discussing unless people develop reading skills. -- ___ Python tracker ___ ___

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: > Stefan Krah added the comment: > > 720MB <= "3-4 dozen" * 20 MB <= 960MB. Per server. > > It has all been said. :-) I don't understand what message you are replying. I'm not interested in the number. Who asked MBs / server? Absolute number is not important

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: 720MB <= "3-4 dozen" * 20 MB <= 960MB. Per server. It has all been said. :-) I don't understand the objections about alignment. malloc() and obmalloc() are at least 8-byte aligned, mmap() with NULL as the first parameter is page-aligned. --

[issue36839] Support the buffer protocol in code objects

Serhiy Storchaka added the comment: Yet one consideration. The bytecode is actually a wordcode, a sequence of 16-bit words, and the start of the array must be properly aligned. There is no problem if it is a data of the bytes object, but if you have a mapping of the pyc file the alignment

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: On Tue, Jun 4, 2019 at 8:45 AM Dino Viehland wrote: > > The 20MB of savings is actually the amount of byte code that exists in the IG > code base. Wait, do you expect you can reduce 100% saving of co_code object? co_code takes 0byte? You said "the overhead it

[issue36839] Support the buffer protocol in code objects

Dino Viehland added the comment: The 20MB of savings is actually the amount of byte code that exists in the IG code base. I was just measuring the web site code, and not the other various Python code in the process (e.g. no std lib code, no 3rd party libraries, etc...). The IG code base

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: On Sun, Jun 02, 2019 at 02:38:21AM +, Inada Naoki wrote: > What instance means? code object? co_code? > Anyway, Dino didn't propose such thing. He only proposed accepting buffer > object for code constructor. > He didn't describe how to use buffer object.

[issue36839] Support the buffer protocol in code objects

Serhiy Storchaka added the comment: The managed buffer can be shared if it refers to the same bytes. But different code objects in the same process refer to different bytes, therefore they should have distinct managed buffers. -- ___ Python

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: > And I understood that Dino proposed to share one code instance as a memory > mapped file for *all* processes. What instance means? code object? co_code? Anyway, Dino didn't propose such thing. He only proposed accepting buffer object for code constructor.

[issue36839] Support the buffer protocol in code objects

Stefan Krah added the comment: The managed buffer can be shared: >>> b = b'12345' >>> m1 = memoryview(b) >>> m2 = memoryview(m1) >>> gc.get_referents(m1)[0] >>> gc.get_referents(m2)[0] And I understood that Dino proposed to share one code instance as a memory mapped file for *all*

[issue36839] Support the buffer protocol in code objects

Serhiy Storchaka added the comment: The size of the code object is at least 144 bytes. >>> def f(): pass ... >>> sys.getsizeof(f.__code__) 144 If the function uses parameters, variables or constants (and you cannot do much useful without using them), their size should be added too. It

[issue36839] Support the buffer protocol in code objects

Serhiy Storchaka added the comment: > * They need to use lightweight object for buffer. At least, > memoryview object is large (192byte > on Python 3.7.3 amd64). Actually it is larger, because you should add the size of internal objects. In 3.8: >>> sys.getsizeof(memoryview(b'')) 184 >>>

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: On Sat, Jun 1, 2019 at 2:47 AM Brett Cannon wrote: > > Brett Cannon added the comment: > > RE: "I think it needs significant benefits for typical users, not only for > Instagram. If only Instagram get benefit from this, keep it as Instagram's > internal

[issue36839] Support the buffer protocol in code objects

Brett Cannon added the comment: RE: "I think it needs significant benefits for typical users, not only for Instagram. If only Instagram get benefit from this, keep it as Instagram's internal patch." But who's typical in this case? You? Me? We're talking code objects, something that the

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: > In the Instagram case there's about 20mb of byte code total and there are 3-4 > dozen worker processes running per server. The byte code also represents the > second largest section of memory as far as serialized code objects are > concerned, the only

[issue36839] Support the buffer protocol in code objects

Dino Viehland added the comment: Well given that we're one day away from 3.8 Beta 1 I'm not going to rush this in :) In particular the discussion has made me wonder if I can also do more with sharing strings using the legacy unicode strings (which I don't believe will require any runtime

[issue36839] Support the buffer protocol in code objects

Brett Cannon added the comment: I agree with Eric. While I understand what Serhiy is saying about code objects being more than a bytearray of bytecode, the buffer protocol is still a view on an object, and that view happens to be for a subset which I think is acceptable as I think of what a

[issue36839] Support the buffer protocol in code objects

Eric Snow added the comment: FWIW, I don't see the problem with supporting any read-only "buffer" object, rather than just bytes objects, for the string of bytes in a code object. That's all that Dino is proposing. The change is not invasive and solves a real need. The additional

[issue36839] Support the buffer protocol in code objects

Serhiy Storchaka added the comment: I concur with Inada. This would add complexity in the code object. Note also that the code object is not just a sequence of bytes. It is a complex object which contains references to a dozen of objects: bytes objects, strings, integers, tuples, dicts. I

[issue36839] Support the buffer protocol in code objects

Dino Viehland added the comment: In the Instagram case there's about 20mb of byte code total and there are 3-4 dozen worker processes running per server. The byte code also represents the second largest section of memory as far as serialized code objects are concerned, the only larger one

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: > Could someone create a buffer object which still allows the underlying memory > to be written? Sure. But I can use ctypes to modify byte code today as well > with something like "ctypes.cast(id(f.__code__.co_code) + 32, > ctypes.POINTER(ctypes.c_char)) [0]

[issue36839] Support the buffer protocol in code objects

Dino Viehland added the comment: Sure, but immutable/const is almost always a language level guarantee. The only case where that's not true is when you have OS/hardware level memory protection and that doesn't apply to any of Python's existing byte codes. So from a Python perspective, code

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: read-only is slightly different than const / immutable. const / immutable means anyone can not modify the memory. read-only means only the memory should not be modified through the buffer. But underlaying memory block can be modified by owner who creates

[issue36839] Support the buffer protocol in code objects

Dino Viehland added the comment: The PR actually checks that the buffer is read-only (this was also a concern that Mark Shannon had). And the Python buffer protocol says that you need to consistently hand out read-only buffers. So while someone could create a buffer and mutate it outside

[issue36839] Support the buffer protocol in code objects

Inada Naoki added the comment: I don't like this. It removes guarantee that code object is constant / immutable. > Because the code objects are on random pages and are ref counted the ref > counts can cause all of the code to not be shared across processes. These ref counts are not

[issue36839] Support the buffer protocol in code objects

Change by Dino Viehland : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36839] Support the buffer protocol in code objects

Change by Dino Viehland : -- keywords: +patch pull_requests: +13093 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36839] Support the buffer protocol in code objects

New submission from Dino Viehland : Many Python deployments involve large code based that are used in scenarios where processes are fork-and-exec'd. When running in these environments code objects can end up occupying a lot of memory. Because the code objects are on random pages and are