06:03 <mattip> it seems the hpy-0.0.4 branch went out of sync with the 0.0.4 release, there is a lot of syncing to do

07:11 <phlebas> cfbolz: why is it more complicated? (just wondering if we overlooked sth, b/c I don't think there's anything particularly complicated in graalpy)

07:14 <cfbolz> phlebas: who allocates the struct in int.__new__

07:15 <cfbolz> And where do you store it?

07:20 <phlebas> we generate a new `__new__`: https://github.com/oracle/graalpython/blob/master/graalpython/com.oracle.graal.python/src/com/oracle/graal/python/builtins/objects/cext/hpy/GraalHPyNodes.java#L2111

07:21 <phlebas> and then we allocate it in https://github.com/oracle/graalpython/blob/39f84e430f18ac16757a0774aa9c8c80dd5adfe1/graalpython/com.oracle.graal.python/src/com/oracle/graal/python/builtins/objects/cext/hpy/GraalHPyObjectBuiltins.java#L175 and attach it to the object

07:22 <phlebas> so it's not in the same memory region, there's a pointer from the managed object to the native memory

07:24 <phlebas> all our objects have room to allocate some "hpyData" anyway (initially just used for HPyFields), but now we use that as a general place to store the native pointer as well as references to HPyFields (and maybe other stuff, fangerer would know better)

07:29 <cfbolz> phlebas: ok, so there's space in *every* object for that?

07:30 <phlebas> yes, right now there is. we initially put it in the attribute storage under a hidden key, but then getting to it requires a map read and when coming from native code that's not ideal

07:30 <cfbolz> ok

07:31 <cfbolz> phlebas: yeah, I think we will go with the map read for subclasses of other classes than object