<headius[m]>
kares: no doubt, great to see these two areas start to unify
<headius[m]>
regarding code cache... I would like to know what's continuing to compile forever
<headius[m]>
one-off generated methods shouldn't JIT, and if they're used heavily they probably should... so I am somewhat reluctant to encourage people to throttle the JIT without knowing why things are jitting
<headius[m]>
enebo: I think we should just go with jnrproject.org
<enebo[m]>
headius sure makes sense and it is not remotely confusing
<headius[m]>
module and package will (eventually) be org.jnrproject
<enebo[m]>
funny how many people use names like jillbilly13 because some others used none-12 :) OSS projects need to go that route
<enebo[m]>
(made up the name jillbilly on the spot...but I bet there is a username like that somewhere)
<headius[m]>
I guarantee there's someone named Jill from Appalachia with that username
<headius[m]>
chrisseaton: so you have used name.com and are happy with it?
<kares[m]>
headius: should have stressed jit-ing after hours of up time (heavy-load). this goes back to Rob's Rails app that we have discusions almost a year back ... would also like to understand why JRuby did not stop JIT-ing
<headius[m]>
one of the tests I do while benchmarking webapps is to turn on JIT logging and make sure it eventually stops
<headius[m]>
there's also JMX endpoints to track it
<headius[m]>
hopefully they're still working, I don't think we have tests
<headius[m]>
$60 for five years of jnrproject.org
<headius[m]>
DM me your credit card number enebo
<enebo[m]>
lol
<headius[m]>
jnrproject.org lives
<csharpsteen[m]>
kares: Thanks for the info! This is JRuby 9.2.11.1. The interesting bit is that _something_ is able to eventually free nearly 50% of the `nonprofiled` methods usage. Since this is Java 11, I'm looking into whether the Java Flight Recorder could shed some light. Looks like it may have some event probes down here in the code cache sweeper.
<headius[m]>
next question is what to do with the dashes in the JNR project names
<headius[m]>
they can't be used as module names
<headius[m]>
org.jnrproject.ffi for jnr-ffi?
<headius[m]>
of course oss.sonatype goes down for maintenance right now
<headius[m]>
these javadoc errors are getting pretty specific
<headius[m]>
[ERROR] /home/runner/work/jnr-ffi/jnr-ffi/src/main/java/jnr/ffi/Pointer.java:29: error: tag not supported in the generated HTML version: tt
<headius[m]>
[ERROR] * This class provides operations on a native memory address. Most <tt>Pointer</tt>instances will represent direct
<headius[m]>
because jnr-constants has a Platform class in the same location as a platform package the strict javadoc kicks it out
<headius[m]>
generally folks shouldn't be poking around in the platform package (that's where the generated constant tables are) so I guess we could rename it?
<headius[m]>
"platforms"
<headius[m]>
why is github's search so fuzzy
<headius[m]>
search for jnr.constants.platform also brings up jnr/constants/platforms
<headius[m]>
-s
<headius[m]>
JRuby itself doesn't reference anything under jnr.constants.platform so I think rename is pretty safe
<headius[m]>
enebo: any objection?
<headius[m]>
I want this release round to also build and test green on Java 11+ without tweaking
<enebo[m]>
yeah I think it is ok. I mean something needs to change so it might as well be with major number change
<headius[m]>
the error is largrely right... on Windows and MacOS you can't have a package platform.html and a class Platform.html
<headius[m]>
I am doing jnr-constants 0.10.0 from 0.9.14 rather than 1.0 ... I think the major flip for each of these should probably update packages to reflect module name
<enebo[m]>
still a siginificant change and based on most peoples general opinions on numbers < 1.0 means developing the final aPI
<headius[m]>
oh drat... actually I just realized EVERYTHING is in this platform dir
<headius[m]>
all the baseline constant enums are there, and then in linux/windows etc subpackages are the platform specific stuff
<headius[m]>
seems like the wrong layout to me... you'd expect all the constant tables to be in jnr.constants
<headius[m]>
I mean all the public enums
<headius[m]>
hmph
<headius[m]>
so this is a much more visible change then
<headius[m]>
so maybe renaming the class is better then