<headius[m]>
this is from someone maintaining Fedora packages, ups minimum to 8 because we need to use this @Native annotation now, and this might even require building using 11 because it uses the new replacement for javah
<headius[m]>
I will confirm if it can build with 8 but it seems like we need to at least target 8 to get fully compatible with 11+
<headius[m]>
ok well this looks fine... the header file support in javac exists in 8
<headius[m]>
but not before... will have to go to 8
<kares[m]>
well first time with the baby so I would say a new experience ;)
<headius[m]>
oh yes, that would definitely change things
<headius[m]>
kares: you have any concerns with jnr moving to 8+?
<headius[m]>
java 8 is 6 years old, java 7 is 9 years old
<kares[m]>
not really every project seems to be 8+ tgese days
<enebo[m]>
headius: sorry was afk
<enebo[m]>
Seems like we could just bump major and change to 8
<headius[m]>
looks like most non-oracle dists are 8 minimum too
<enebo[m]>
then no one can complain about being surprised
<headius[m]>
enebo: yeah I realized that we should bump something more thann x.x.y
<headius[m]>
we have a 1.3 milestone that was intended to be a rebuild of all binaries for new features, but we still have no way to rebuild across all platforms
<enebo[m]>
but Java < 8 seems like we should not be criticized too much at this point
<headius[m]>
(specifically there is an old PR to add support for additional libdl features that would require a rebuild)
<headius[m]>
so I guess we can make a 1.4 or 2.0 be the big rebuild
<enebo[m]>
I am positive there are Java 7- users somewhere but if you combine that with the fact it is our jnr libs I feel the possible pool may not be real large to begin with
<headius[m]>
I would also like to try to implement a "super posix_spawn" based on fork+exec that we can use across platforms that can fork+exec
<enebo[m]>
yeah we should just use another number when we can rebuild
<enebo[m]>
but as you know we have talked a lot about redoing all this somehow for maintenance reasons
<headius[m]>
anyone using jnr besides us is almost certainly 8+ right now
<headius[m]>
yeah
<enebo[m]>
So there is that as well
<headius[m]>
ok I am going to rename 1.3 to 2.0 and make the next 1.2.x with this change be 1.3
<enebo[m]>
headius: maybe time for you to tweet out on getting someone to make a helix-like set of build images :)
<headius[m]>
if someone is desperate for a java 7 compatible 1.2.x later on it's just a matter of spinning bits
<headius[m]>
heh yeah
<enebo[m]>
we haven't done it and we likely will not at the rate of things
<headius[m]>
I don't know what the state of the art is for building a large project made up of many independent parts that should version together
<enebo[m]>
but that is true re Java 7...it is open source
<headius[m]>
one repo seems wrong but many repos is a PITA
<headius[m]>
moving to 1.3 will mean 1.2 line can still support new releases if necessary... that eliminates my concern
<enebo[m]>
well one repo might be right with n maven projects
<headius[m]>
you just won't be able to both build on 11 and run on 7
<enebo[m]>
top-level command just builds them all whether anything changes or not
<enebo[m]>
seems a bit dogmatic I suppose but at this point it would eliminate a lot of occasional pain
<headius[m]>
this is mostly dealing with the target version (11+ don't support 6 or 7) and the removal of the javah tool (it has been integrated into javac since 8)
<headius[m]>
this will also let us start modularizing jnr
<headius[m]>
could not do that with 1.6 target bytecode
<headius[m]>
ok I will proceed then
<enebo[m]>
yeah I have zero fear of that change so long as we use a signifcant version change
<headius[m]>
and I guess bump the other jnr projects to 8 too
<enebo[m]>
yeah
<enebo[m]>
definitely...THE WHOLE BANDAID
<headius[m]>
a couple of them are 0.x still
<headius[m]>
I guess I go to 1.0?
<enebo[m]>
sure...I mean how old are these projects...they earned it
<headius[m]>
yeah
<headius[m]>
it's just a number
<enebo[m]>
It is quite funny to even think we left these points for so long
<enebo[m]>
yes definitely true
<enebo[m]>
we will be doing Firefox numbering once the covid cure comes in
<headius[m]>
yeah these were basically the version without the point
<headius[m]>
35, 36, 37
<enebo[m]>
9000
<headius[m]>
we could pull a JRuby 9000 and just make next version the two-digit value
<enebo[m]>
we do seem to work on a similar wavelength
<headius[m]>
I think 1.0 is better though 😆
<enebo[m]>
I agree we should use 1.0
<enebo[m]>
after all covid has no vaccine
<headius[m]>
jnr-19
<headius[m]>
I'll proceed with this assuming I can get ant updated on travis (it doesn't support the javac ant task's "nativeheaderdir")
<headius[m]>
enebo: I am going to add automatic module names to the manifests for these libraries
<headius[m]>
but I refuse to use either kenai or github in that name, like wmeissner was using for packages
<headius[m]>
<groupId>com.github.jnr</groupId>
<headius[m]>
<artifactId>jffi</artifactId>
<enebo[m]>
haha
<headius[m]>
so there's a few factors here
<enebo[m]>
yeah it was not the right choice but he had his beliefs
<headius[m]>
sonatype strongly recommends that the group ID be a reversed domain name
<headius[m]>
I'm not saying we are changing that groupID right now but having it not match the module might be weird
<headius[m]>
honestly the name I want would be just jnr.X
<headius[m]>
jnr.jffi, jnr.jnr-ffi, etc
<headius[m]>
it could move under org.jruby but that kinda ties it to jruby in a weird way
<headius[m]>
groupID: org.jruby.jnr
<headius[m]>
if we had a home domain for the project we could use that
<headius[m]>
"Maven does not enforce this rule. There are many legacy projects that do not follow this convention and instead use single word group IDs. However, it will be difficult to get a new single word group ID approved for inclusion in the Maven Central repository."
<enebo[m]>
what will they do sue us?
<enebo[m]>
I say jnr.
<enebo[m]>
It is amusing how archaic the notion is that something is not just the name of the project...where it lives is not something which stays the same
<headius[m]>
from Stephen Colebourne:
<headius[m]>
TL;DR - My best practices
<headius[m]>
These are my recommendations for module naming:
<headius[m]>
Module names must be reverse-DNS, just like package names, e.g. org.joda.time.
<enebo[m]>
I guess org.jnr could be considered more OSS
<headius[m]>
I could see if domains are available
<headius[m]>
three-letter will almost certainly be taken
<enebo[m]>
yeah if so then it can conform to that
<enebo[m]>
"must"
<enebo[m]>
as a best practice
<enebo[m]>
I mean that is a little conflicting
<enebo[m]>
in the modern age though these are all maven artifacts with metadata anyways...
<headius[m]>
my general thought is that whatever we pick here should eventually become the new groupID
<headius[m]>
so I guess jnr would be difficult to get approved
<chrisseaton[m]>
Maybe someone should buy a really simple TLD like open.org (I know that's not available) then people could get subdomains for free for their projects.
<enebo[m]>
org.jnr seems like it would solve the problem
<headius[m]>
it's taken
<enebo[m]>
if that is available
<enebo[m]>
ahj
<headius[m]>
jnr.xxx
<headius[m]>
oh don't click that
<enebo[m]>
300$ renewal
<headius[m]>
I don't know what's there but don't click it
<enebo[m]>
ahahah
<enebo[m]>
goat cx
<headius[m]>
there are a million TLDs now so we can certainly get one
<headius[m]>
chrisseaton: yeah I wonder if anything like that exists
<enebo[m]>
chrisseaton: yeah although we know open.org is taken without looking
<headius[m]>
I never liked that wayne put github and kenai in those names because they're not our domains
<enebo[m]>
it is closed so to speak
<headius[m]>
oh and making this even more confusing...
<headius[m]>
package com.kenai.jffi.internal;
<headius[m]>
so package and groupID already don't match
<headius[m]>
and I think the other JFFI projects use yet another package layout
<enebo[m]>
do you want to boil this ocean today?
<headius[m]>
yeah they use jnr.x
<headius[m]>
I don't want to boil any ocean but if this is the Java 11+ release I want to have basic module name in there
<enebo[m]>
because atm wouldn't the easiest just to update the version and push
<enebo[m]>
oh right module name
<headius[m]>
all I want to fix today is module name
<enebo[m]>
I already forgot
<headius[m]>
we can fix maven and packages in a big major version sweep later
<enebo[m]>
oss.jnr
<enebo[m]>
is that a thing?
<headius[m]>
hmm
<enebo[m]>
jnr.oss
<headius[m]>
I guess we should just decide on a tld and get it
<enebo[m]>
yeah probably a good idea if we want a website to match the package
<headius[m]>
heh
<headius[m]>
yes
<enebo[m]>
for jnr personally I do not really care but if we pick one which is not taken we should
<headius[m]>
I am searching on godaddy but don't want to register there if I can avoid it... suggestions welcome
<enebo[m]>
dynadot I have used
<chrisseaton[m]>
name.com
<headius[m]>
nice, only $10k for jnr.org
<headius[m]>
it's a steal
<headius[m]>
what's with these prices?
<headius[m]>
oh I see the "premium" ones are the ones taken by someone else
<headius[m]>
jnr.ninja
<chrisseaton[m]>
three-letters? That's valuable no matter what they are!
<headius[m]>
jnr.cc is available
<headius[m]>
cheap
<headius[m]>
heh there is a java tld but we could never use that
<headius[m]>
package java.jnr
<chrisseaton[m]>
Do you not want to brand under JRuby? org.jruby.jnr? It'd promote what JRuby are doing to non-jruby people.
<headius[m]>
it is an option but the jnr projects are independent of jruby
<headius[m]>
I have used com.headius for projects I originated to avoid association with jruby
<headius[m]>
well I'm thinking jnr.cc or just punt for now
<headius[m]>
I'd really like to have a module name though
<headius[m]>
hmm there's no .project but there's a .pro
<headius[m]>
oh .info isn't bad either
<headius[m]>
we could also just do something like jnrproject and have any domain name
<enebo[m]>
I would go with cheapest tld
<enebo[m]>
or just ignore the not mandatory mandate
<headius[m]>
cc is short and other services use it like tinyurl
<headius[m]>
some island nation off Australia
<enebo[m]>
nice
<headius[m]>
"The name of a module should correspond to the name of its principal exported package. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should still start with the reversed form of an Internet domain with which its author is associated."
<headius[m]>
from JLS
<headius[m]>
cc.jnr is pretty reasonable for package, groupID, and module
<headius[m]>
.dev is taken, .info is taken, .tech is taken
<enebo[m]>
.tv
<headius[m]>
I'm scrolling through a list of available ones now
<enebo[m]>
only 500$/year
<headius[m]>
some are fine as domain but weird as a package or module name, like jnr.news
<headius[m]>
I will punt on this until tomorrow and let poll run
<headius[m]>
run fits well with runtime
<csharpsteen[m]>
Hey folks 👋
<csharpsteen[m]>
I'm trying to wrap my head around how the JRuby 9 JIT interacts with the Java CodeCache. Specifically, if JRuby decides to create a `CompiledIRMethod`, does that have a different interaction with CodeCache sweeper behavior like `UseCodeCacheFlushing` that may decide to discard native code based on the "hotness" that the JVM has computed?
<headius[m]>
Hi there!
<headius[m]>
Jruby's jit usually will put each jit compiled method into its own class loader
<headius[m]>
From there it is just a standard piece of jvm bytecode so it interacts like any other dynamically generated code
<csharpsteen[m]>
To add some context, I'm trying to debug some bad performance that occurs around dips like this in the `nonprofiledmethods` segment of the CodeCache on Java 11:
<csharpsteen[m]>
JRuby performance gets bad preceding the drop, then the JVM shakes its self out of it once `used` is knocked down.
<csharpsteen[m]>
I was thinking we may just need to tell the code cache sweeper to be more aggressive by increasing `-XX:StartAggressiveSweepingAt=`, but the drop occurs after `nonprofiledmethods` has been over 90% full for a while.
<csharpsteen[m]>
So, I'm wondering if the code produced by JRuby JIT has different rules around whether it lives or dies.
<headius[m]>
I have never looked at these metrics, but it shouldn't be any different
<headius[m]>
we don't do anything unusual other than classloader-per-method which is not uncommon for code-generation
<headius[m]>
I would like to hear more about this from your end though... we have long suspected we might want to recommend different code cache settings for JRuby users
<headius[m]>
we just don't have big apps to test with
<csharpsteen[m]>
Heh, I've gone from being vaguely aware of code cache two weeks ago to reading through `src/hotspot/share/runtime/sweeper.hpp` today, so I'm very much feeling my way through this :P
<headius[m]>
hah ok I understand
<headius[m]>
this is an interesting discovery though
<csharpsteen[m]>
From what I've read it seems that Java's JIT can decide to de-optimize a method by throwing the compiled code away and returning to interpreted execution.
<csharpsteen[m]>
I'm wondering if JRuby JIT changes the availability of that decision when it creates a `CompiledIRMethod` object.
<csharpsteen[m]>
E.g. it's no longer easy for the JVM to say "code cache is getting a little tight, let's de-optimize some methods".
natemccurdy[m] has joined #jruby
<headius[m]>
no, nothing about CompiledIRMethod or our jit process should change that
<headius[m]>
CompiledIRMethod just wraps generated bytecode which we isolate into its own classloader... that bytecode should behave like anything else on JVM, getting native compiled when hot enough and thrown away (reverted to bytecode interpreter) when it gets old
<headius[m]>
depending on the app, we may generate a lot of code, so that could certainly put more pressure on code cache
<csharpsteen[m]>
Gotcha. So, JRuby JIT is "JIT to JVM bytecode" not "JIT to native"? That may be what I was misunderstanding.
<headius[m]>
that's right
<headius[m]>
it's "just in time" so we don't end up throwing gobs of bytecode at the JVM for methods that are only called once
<headius[m]>
current threshold is 50 calls before we "JIT" to bytecode, otherwise we use our own interpreter
<headius[m]>
so think of JRuby as a little VM on top of JVM, and our JIT output is just bytecode
<csharpsteen[m]>
Awesome, thanks for the info!
<csharpsteen[m]>
The app in question is Puppet Server, so we're likely taking some sub-optimal behavior and then multiplying it by 10x or 20x by running that many distinct `ScriptingContainer` instances.
<headius[m]>
Aha yeah that would definitely multiply the problem
<headius[m]>
it's not really possible to share the bytecode across containers because they depend on instance-specific data for caching and such
<csharpsteen[m]>
Yeah. They've been working on getting everything to run multi-threaded in a single `ScriptingContainer` but it's a large ecosystem that hasn't had to think about "thread safety" before. So, it's a process ;)
<headius[m]>
yeah I can imagine... that's the golden path but we know it's difficult sometimes
<headius[m]>
jnr.run is winning but jnrproject.org is catching up
<lopex>
numbers everywhere
<headius[m]>
ok I read something wrong... jnr.run is not really available, it's squatted by some commercial domain provider
<headius[m]>
as part of their "premium" domains
<headius[m]>
so I'm thinking jnrproject.org is going to be it
<lopex>
is it a voting campaign ?
<headius[m]>
I posted a poll on Twitter
<lopex>
ah I almost gathered
<headius[m]>
most of the new TLDs are not great matches for package names etc
<headius[m]>
org.jnrproject is ok
<lopex>
so a brand new domain for a project ?
<lopex>
what is the usage for jnr in general ?
<lopex>
outside jruby
nirvdrum has quit [Ping timeout: 265 seconds]
<csharpsteen[m]>
I seem to recall Jetty using JNR to enable listening on UNIX Sockets.