<arigato>
I'm getting flag = '\x06' if I set PYPY_GC_MAX_PINNED to 0
<arigato>
but still no crash
<krono>
With max_pinnend =0 I never got a crash, tho
<krono>
only _without_
<arigato>
OK
<krono>
thats somehow embarrasing
<arigato>
well, it occurs. I'm as embarrassed at you are
<arigato>
it can be that you ran things slightly differently yesterday, or else just some internal randomness
<krono>
Im going back to the state where RSDL was in and see what happens
<krono>
my RSqueakvm still has this behavior
<arigato>
makes sense
<arigato>
if you reproduce it with RSDL I can try to run it too
<krono>
note that I use release-pypy2.7-v7.1.1 tag as my base pypy
<krono>
(but I verified the existence of the problem day-before-yesterday with default too)
<krono>
yes
<krono>
arigato: can you try an --lldebug0 build?
<arigato>
yes, let me try
<arigato>
ah, crash
<arigato>
good
<krono>
o_O
<krono>
so its the lldebug thing
<arigato>
it's an assertion that is triggered by --lldebug0, but I think the assertion makes sense. in non-debug mode it would instead do potential nonsense
<arigato>
so it actually makes no sense that we get flag = \x05 here
<arigato>
because they are all prebuilt string objects
<arigato>
for some reason, "0" is allocated dynamically
<arigato>
that might be a very bad reason, like "it's a char!" and then it's transformed into a string dynamically
<arigato>
it's unpinning a different object than the one it pinned
<arigato>
aaaaaa
<arigato>
"it's a char, let's make a string" occurs twice
<arigato>
one copy is pinned, and the other is unpinned
antocuni has joined #pypy
speeder39_ has joined #pypy
<arigato>
I don't see how to fix the existing API rffi.get_nonmovingbuffer()
<arigato>
I fear it needs changing
<krono>
(sorry, had to read something)
<krono>
that sounds not too good.
<krono>
I think I'll do with max_pinned = 0 for now.
<krono>
Thanks for loking into it :)
<arigato>
NP
themsay has joined #pypy
<arigato>
cfbolz: do you have an opinion? I'm thinking about renaming rffi.get_nonmovingbuffer() into rffi.get_nonmovingbuffer_ll() and make it take an llstr as argument
<arigato>
then we can be more or less sure to pass the same llstr to the next rffi.free_nonmovingbuffer_ll()
* cfbolz
reading
<arigato>
these functions are used a few times left and right including in pypy/module/*, but mostly they are used by rffi.llexternal(), which can be fixed internally
<cfbolz>
Right, I see how the bug occurs
<cfbolz>
arigato: if we change the API, can we somehow have a more high level new one that the existing non llexternal users can migrate to? A with statement?
<arigato>
we already have, actually
<arigato>
they can say "with scoped_nonmovingbuffer(data)"
<arigato>
this API would remain
<cfbolz>
Great
<arigato>
or "with scoped_view_charp" for the case where they want a null-terminated "char *"
<cfbolz>
Then the dangerous API should just go away indeed
<arigato>
well I fear it's still used a few times directly, because not all code can easily match a with statement
<cfbolz>
arigato: OK, but those places should llstr then?
<arigato>
yes
<cfbolz>
Ok
<arigato>
they are already hacking around by using get_nonmovingbuffer() directly
<arigato>
I'm sure they could be rewritten without it, but possibly at a performance loss
<cfbolz>
arigato: can you have the old function stay around and raise an exception with an explanation what to use instead?
xcm has quit [Remote host closed the connection]
<arigato>
yes
<arigato>
good idea
xcm has joined #pypy
<cfbolz>
Cool
<cfbolz>
(maybe with @not_rpython to make sure the exception doesn't accidentally translate)
<arigato>
...yes, @not_rpython is a better idea than writing an XXX inside the function
<cfbolz>
arigato: :-)
<cfbolz>
Or ... which has now become valid Syntax
<arigato>
yay!
<cfbolz>
arigato: a bit of a different topic, would you be up for reviewing my completely overengineered improved json parser next week or so?
<arigato>
:-)
<arigato>
yes
<wleslie>
SysExcInfoRestorer is a much more descriptive name than EXCEPT_HANDLER. thanks pypy3 team.
<cfbolz>
arigato: cool, will ping you at some point
<cfbolz>
(unfortunately v8's newest version has a much better new one too, so we are losing against them again, but I am going to ignore that for now)
<cfbolz>
wleslie: \o/
<krono>
thank you for tackling this :)
xcm is now known as Guest36942
Guest36942 has quit [Killed (hitchcock.freenode.net (Nickname regained by services))]
<mjacob>
so after a reload, the archive is up to date
<mjacob>
weird
speeder39_ has quit [Quit: Connection closed for inactivity]
glyph has quit [Ping timeout: 248 seconds]
bendlas has quit [Ping timeout: 250 seconds]
edd[m] has quit [Ping timeout: 265 seconds]
hbx6 has quit [Ping timeout: 264 seconds]
glyph has joined #pypy
<krono>
so for rffi. If I have a function that returns rffi.CCHARP, I can use rff.charp2str to get a python level string. What do I use for the ones returning a CONST_CCHARP?
<arigato>
uh, good question. we have mostly ignored the "const" in C
<arigato>
I guess you should just declare the function as returning a CCHARP
<arigato>
or do rffi.cast()
<krono>
ok. It originally said CCHARP but that results in annoying Red Paint on my terminal during the C compile step ;)
<krono>
I leave it as is :)
<arigato>
right :-) yes, you can return CONST_CCHARP and add a rffi.cast then
<arigato>
(I think the cast doesn't cause a C warning?)
<krono>
I haven't tried. However, this is all bikeshedding from what I actually have to do, so I better leave it as is :D
<arigato>
right. yes, I think we're getting Red Paint about that in a pypy translation
antocuni has quit [Ping timeout: 268 seconds]
<krono>
:)
xcm has quit [Remote host closed the connection]
dddddd has joined #pypy
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
bendlas has joined #pypy
<kenaan>
arigo default 19e211d4c76b /: Change the API of rffi.get_nonmovingbuffer(), now renamed to rffi.get_nonmovingbuffer_ll(), because it is not safe:...
<kenaan>
arigo default 3576fb517a7b /rpython/memory/gc/env.py: Broken line, get_L2cache_linux2_cpuinfo_s390x() was never called. Comment it out entirely instead of fixing the ca...
<fijal>
arigato: should we quickly do threadlocals?
<fijal>
I *think* it's the only one left
<fijal>
there is also singlefloats I guess
<tos9>
argh frigging mercurial. I did some copyediting, and then pulled the Tweaks commit, and then fixed the merges, and then hg now threw that merge resolution away somehow
<tos9>
hopefully that didn't change the meaning of anything there though I had a hard time guessing what you meant by "old crappy code" :)
<tos9>
also I think all those warnings are a bit distracting... maybe it's more "impressive" sounding while still being scientifically honest if they go to the bottom after the key results are presented?
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<fijal>
tos9: which warnings? that the benchmark setup is shit?
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
<fijal>
krono: it cannot be elided with p572 being a pointer
<fijal>
er, being a variable
<fijal>
so what you need is to make it constant, either by promotion or other means
<krono>
fijal: thank, that helps
<kenaan>
Raemi extradoc 925d7c1b0666 /blog/draft/: trying to make the blog post a bit more appealing :)
<Remi_M>
@fijal: I hope you don't mind the changes. I think that the pictures are a bit more appealing than the table :)
<fijal>
yeah sure, thanks a lot!
<krono>
err, what's an getinteriorfield_gc_r ? is that new?
<fijal>
it's a read from an array of structs (inlined)
<fijal>
no, it's not new
<fijal>
you would see it for dicts for example
<krono>
that's interesting, never had that up until now
<arigato>
fijal: sorry, back now. Did you finish threadlocals?
<fijal>
arigato: I think so, waiting for the tests
<arigato>
cool
<fijal>
then will kick a translation
Remi_M has quit [Quit: See you!]
<fijal>
arigato: is there anything else of value in those oopspec calls?
<fijal>
for ARM the rest is 32bit only
<krono>
fijal: sorry to bother you with the stuff above, but the p572 is read from a field that is in _immutable_fields_ , so I thought it would be constant already
<fijal>
krono: copy paste the read operation please
<fijal>
krono: no no no, it does not bother me at all happy to be of service :-)
<fijal>
krono: right so the problem is that it's a read from a constant dict
<fijal>
but we don't know that
<fijal>
so what we do in such situation is to put it behind elidable: @jit.elidable def read_map(self, key): return self.map[key]
<fijal>
or something like that
<krono>
yea, sounds reasonable...
<krono>
let me thinkg for a minute
<krono>
(so the difference to the _other_ two vms where that is not present is that here the holder of p572 has _attrs_ (== _immutable_fields_ ) and in the others, no _attrs_)
<krono>
but I'll try withan elidabe getter, be back in 10 minutes
<krono>
fijal: just quick before I translate, can the edliable getter also set? a bit like setdefault?
<arigato>
yes, "elidable" means that when the same function is called twice with same arguments, then the result must be the same
<krono>
thought so, just wanted to be sure.
<krono>
thanks. *transalting now*
<arigato>
to be precise, when you call an elidable function, the JIT collapses several calls into one, and the one remaining call could occur earlier than it should really occur according to the rpython program flow
<arigato>
be careful when you initialize stuff on an instance and then immediately pass that instance (as a constant) to an elidable call, because the elidable call can occur earlier
<fijal>
but *also* can be removed completely on constants
<fijal>
so you can set things up, but you have to be careful that there are no observable side effects
<arigato>
right, but that's a special case where the call occurs only once during JITing
<fijal>
arigato: tests seem to pass, if that stuff is tested at all
<fijal>
uh, is the USE__THREAD=False not disabling that somehow?
<arigato>
I have no clue how this call can remain
<arigato>
_prepare_op_call() looks like it should kill it, it has got the right EF=1 OS=5
<arigato>
wrong version of pypy-c?
* fijal
looks
<fijal>
6885d94b89cf
<fijal>
looks right to me?
<arigato>
yes
<fijal>
🤷♂️
<fijal>
gdb time?
sknebel_ has joined #pypy
<arigato>
guess so
<arigato>
aaaaaaaah no wait
<arigato>
we see this line in the log, that's actually expected
<arigato>
it doesn't mean it was implemented as a call in assembler
<arigato>
we probably did self.assembler.threadlocalref_get(), which emitted non-calls, but from the point of view of the resop, it's still the call shown above
<arigato>
you can't be sure without looking at the actual assembler :-)