<headius[m]>
It definitely looks like it's not parallelizing
<headius[m]>
First question I need to ask is if you need to deploy this with Tomcat or if you could use a ruby based server
nirvdrum has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
<headius[m]>
joao.correia: depending on how you packaged the app for tomcat it may be bottlenecking on how it hands out Ruby inistances, like it may be set up to serialize access to a single JRuby instance rather than letting multiple threads use it concurrently
<headius[m]>
enebo: Vladimir Ivanov may have found the problem causing inlining issues
<headius[m]>
he noticed that the indy call to our generated code failed because it looked like java.lang.String had not been resolved in the classloader... but he also noticed it seemed to be loaded from our classloader
<headius[m]>
I suspect our self-first classloading may be rehoming some JDK classes into another level of classloader and mucking with the type checking across those boundaries
<chrisseaton[m]>
Is this the issue I found?
<headius[m]>
chrisseaton: yes
<headius[m]>
this is just a theory though
<headius[m]>
a quick check with your example case does appear to inline now
<headius[m]>
if I remove the offending classloader
<headius[m]>
First question I need to ask is if you need to deploy this with Tomcat or if you could use a ruby based server
<enebo[m]>
neat CL
<headius[m]>
enebo: ahorek added SocketMessage constants to jnr-constants so I'm spinning a few jnr releases
<headius[m]>
there are PRs for JRuby that depend on his change
<enebo[m]>
ok
<headius[m]>
constants, enxio, unixsocket, and posix all need to go
<headius[m]>
chrisseaton: did you get a binary zero build somewhere or build yourself?
<headius[m]>
I don't have another Big Sur machine to build from
<headius[m]>
ahorek: are you around?
<headius[m]>
I am getting your patches released now but we could chat a moment about the underscore names and those SOL_ constants
<headius[m]>
Sysconf train has sailed I think, very likely other dependencies want those to stay as is
<headius[m]>
GH having troubles today
<headius[m]>
ahorek: yeah I feel bad I did not have a linux machine to test on... I assumed that was the only thing that would need to change
<headius[m]>
I need to get a better rig set up for verifying linux... I suppose just a container would be fine
<headius[m]>
So I dunno if we need those SOL constants or not. We can certainly add them, but if IPPROTO should be preferred then it's not a high priority
<headius[m]>
chrisseaton: great, thanks... I am willing to go through the hassle of building but if I can find someone who already has a build that's clearly easier
<chrisseaton[m]>
I was hoping to do a lot with this dev unit... but things got the better of me.
<headius[m]>
there will be a few layers of work on this, starting with jnr-ffi
<headius[m]>
but I'd like use to have everything in place for JRuby once proper openjdk builds land
<headius[m]>
ok I'm tagging off that server_loop spec until we can figure out why it's sporadic on JDK 11+
<chrisseaton[m]>
https://github.com/apple/openjdk apparently it's just this and `build.sh` and it's configured to be zero by default
<headius[m]>
yeah but doesn't that require a bootstrap JVM?
<headius[m]>
or will doing that give me an aarch64 zero build on my x86_64 Mojave xcode?
<headius[m]>
I guess that's what isn't clear to me... if I need to bootstrap from x86_64 then I need to specify that it should build aarch64 for macos and I don't know how to do that exactly
<chrisseaton[m]>
You can run the bootstrap one through Rosetta, so just a stock one is fine
<headius[m]>
gotta say, this apple DTK machine feels slow
<headius[m]>
dunno how much of that is rosetta stuff getting in the way
<chrisseaton[m]>
You're probably used to a MacBook Pro so much - have you tried to develop on even an Air for example? Really huge huge difference it's very surprising.
<headius[m]>
sure, I don't expect it to perform like an i7, even one from 2017
<headius[m]>
but it's an overall feel thing too... even native Apple apps are noticeably more sluggish
<chrisseaton[m]>
I'm also not sure if it's the actual chip they're going to use or just some ARM chip out of the Apple TV?
<headius[m]>
I thought I read this is roughly equivalent to what's in an iPad
<chrisseaton[m]>
Careful not to discuss perf though - I think you said you wouldn't when you agreed.
<headius[m]>
iPad proish
<headius[m]>
well, I have no expectations of performance on zero, clearly
<byteit101[m]>
Also looks like I need to rebase those. Any eta on a review of the questions at the top of that? (don't want to distract from perf work, keep up the good job!)
<headius[m]>
byteit101: it's not that I don't want to review it, it's that concrete extension code is frightening 😀
<headius[m]>
I will have a look this afternoon and try to resolve it
<headius[m]>
yay looks like I have an openjdk build running on apple arm
<byteit101[m]>
Is it like the brutalist concrete buildings of a few decades ago? :-D
<byteit101[m]>
headius: new pr for the related (jrubyc) changes or add to the concrete pr?
<headius[m]>
I think make a new one that depends on those commits so we can close out the original without reviewing new stuff
<headius[m]>
enebo: could use your eyes on that PR too so we can get it merged in
<enebo[m]>
headius: I was already ok with this pending kares reviewing it
<headius[m]>
ok then I may not have much more to add
<headius[m]>
I will take a quick look over it again though
<headius[m]>
woot, macosx-aarch64-zero-release openjdk building now
<chrisseaton[m]>
Was it as simple as we thought?
<enebo[m]>
I think last comment of kares adds idea of not FQN of class but that need not be in this PR and could be a followup if that actually makes sense as an enhancement
<enebo[m]>
It would look nicer but it definitely would make this feature more complicated
<headius[m]>
seems to be... I had to use 13 instead of 14 as bootstrap, use homebrew to install autoconf, and manually install an updated fiddle for homebrew
<headius[m]>
enebo: yeah that seems fine
<byteit101[m]>
the big questions I had were the 4 at the top in bullets
<headius[m]>
byteit101: for that, just using Kernel#warn seems appropriate
<byteit101[m]>
oh, and 7abe7eb on that branch was intended to address kares' comment. I didn't comment that I had pushed that, but it does show up in the GH PR
<headius[m]>
ah yes ok
<headius[m]>
yeah I would say move STDERR.puts to "warn" and that can be resolved
<headius[m]>
I'm not sure what he means by native end but if we need to do this on the Java side it would be runtime.getWarnings().warn()
<headius[m]>
or warning() for the only-when-verbose warning
<byteit101[m]>
headius: Cool, I'll rebase, squash(?) and update the pr then
<headius[m]>
you don't need to squash
<headius[m]>
and you can probably just merge if you prefer, I don't see any reason we can't merge the PR in its current structure
<byteit101[m]>
This branch has conflicts that must be resolved
<headius[m]>
what do you mean by "MethodData generalization: are the LocalMethodData constants reasonable?"
<byteit101[m]>
> you can probably remove all the attribution here and add yourself if you like
<byteit101[m]>
^ does that mean the Copyright xxx or the @author, and for which add or remove?
<headius[m]>
well for a brand new file you should be the only copyright and author, but you can omit them altogether if you like
<headius[m]>
I'm going to assume enebo is happy with the parser changes
<enebo[m]>
headius: sure
<headius[m]>
submitted review and looking at your remaining questions, byteit101
<byteit101[m]>
I split MethodData into LocalMethodData and OverrideMethodData. I hardcoded is final, is private, and isimplemented for the LMD. Are those good values?
<byteit101[m]>
overrideMethodData I wasn't sure what getDeclaringClass was about, so left it commented out right now (seems to work) and am just wondering if it's necessary or I can remove that along with hasPublicDecl
<headius[m]>
oh I see
<byteit101[m]>
as for attribution, are you suggeesting I remove everyone in AnnotationVisitor and replace them with a blanket " * Copyright (C) 2001-2020 JRuby Contributors"
<headius[m]>
if they're getDeclaringClass is not being used for any of this, it's fine to remove
<headius[m]>
-they're
Osho has quit [Ping timeout: 265 seconds]
Osho has joined #jruby
<headius[m]>
byteit101: my comment for your 4 questions is in, I'll bbiab
<byteit101[m]>
headius: thanks, I added a clarification (I hope) on q#2
ur5us has joined #jruby
_whitelogger has joined #jruby
<headius[m]>
byteit101: I replied regarding reified vs proxy
<headius[m]>
byteit101: and re: attribution, yeah that has been what I have been using going forward, or nothing at all
<headius[m]>
AnnotationVisitor is fully new in this PR right?
<byteit101[m]>
yes
<headius[m]>
ok
<headius[m]>
I just didn't want to have those other copyright lines infect another file
<byteit101[m]>
I just copied it from some other file
<byteit101[m]>
*it = the license block
<byteit101[m]>
headius: pushed license fix & commented again. I have no strong opinion, but wanted to see if others did
<headius[m]>
ok
<headius[m]>
maybe we should consider versioning some intellij settings so new files get appropriate headers, default file formatting always reflects our standard, etc