<lavamind[m]>
I'm considering dropping armhf builds but maybe those errors are harmless ?
<lavamind[m]>
The other specs and mri tests seems to be OK, just spec-ffi is still having issues
<headius>
lavamind: if those traces are accurate they don't make much sense... all failed allocating some normal JVM object flags in our IR
<headius>
I assume since they are FFI tests something else is triggering a memory fault but without the JVM dump I'm not sure I tell where it is happening
<headius>
* sure I can tell where
<headius>
possible that some bad FFI allocation or deallocation is interfering with the operation of the JVM
<lavamind[m]>
oh I see
<lavamind[m]>
well I admit that's a bit beyond me, I'm not even sure if I can provide you with a JVM dump from this environment
<lavamind[m]>
and to be honest there seem to be so many issues with AMR 32-bit that I'm tempted to just drop these builds
<lavamind[m]>
s/AMR/ARM/
<lavamind[m]>
on the topic of FFI I'm wondering if there's a new release upcoming, with all the patches we merged ?
<lavamind[m]>
looking back I think we have a few bits missing for riscv64 in build.xml
<headius>
lavamind: yeah we are on the cusp of 9.3 and 9.4 updates
<headius>
enebo: I finally ran a quick profile of a railsbench run and it's dominated by method lookup
<headius>
so more motivation to finally get all call paths caching (super, refinements, others do not cache at all right now)
<enebo[m]>
yeah
<headius>
two out of three top profiled methods are method lookup related... the other one is string code range munging
<headius>
which perhaps indicates some use case that's not optimized well
<headius>
14-15% of samples were in method lookup
<headius>
this is still sqlite so I am also trying to investigate the impact of JNI
<headius>
mysql may be a lot better since it would be pure java
<enebo[m]>
code range is something I think can be improved. but I am pretty curious when it is happening
<headius>
looks like a number of them are cat operations called from within a gsub
<headius>
encode_www_form_component in uri
<headius>
action_view tag_helper
<headius>
it's spread out over a few things
<headius>
39.7GB of int[] alloc in this run... guess what that's from
<enebo[m]>
gsub is potentially rough but if the src and replacement are both valid it should still be valid and not require CR calc
<headius>
63% of all allocations this run
<headius>
it's joni
<headius>
machine allocs
<enebo[m]>
I think an issue though is UTF-8 if it contains mbc then we are in a bad spot unless we calc CR as we go in gsub
<enebo[m]>
which may be a good idea
<enebo[m]>
since we are walking it anyways
<headius>
we may be failing to mark some things as 7 bit
<headius>
we have very little logic to audit that
<enebo[m]>
yeah it could be
<enebo[m]>
It would not surprise me tbh
<headius>
yeah these method lookups mostly look like super calls
<headius>
fits my thesis that we're mostly not fast on things because we don't optimize a bunch of calls
<headius>
surprising amount of refined calls in this profile too
<headius>
totally uncached of course
<headius>
enebo: a fair amount of uncached lookups to support to_h checks on incoming kwarguments, it looks like
<headius>
any TypeConverter paths that are uncached should be investigated