Repository navigation
Replies: 3 comments 3 replies
|
Related issue to make the AppCDS cache location configurable, with a safer default: #9667 |
Given the friction required to opt-in and many CLI-users' likely lack of awareness about Java/JRuby specifics, I think the "on-by-default" semantics are probably the right way here, if it tends to generate a useful cache. Effectively these problems were more obscure edge cases and seem to me to fundamentally be JDK bugs (/usability issues?) which could be raised and eventually fixed if anyone had the energy/connections to do so.
I find it difficult to follow the original issue, but I thought you had already done something like this? Did I misread?
This seems pretty blunt a hammer. Are we aware of anything other than the empty directory problems which would break AppCDS? This is probably not a good idea, but another alternative may be to somehow hook/trap shell exit in a way that the "sealing violation" can be detected and the cache can be automatically removed/invalidated for next launch; but that would likely add overhead, as well as not being an effective fix for the symlink problem either. So far the issues seems pretty isolated/obscure to me, so maybe better to keep an eye on it and in the meantime just see if the JDK team are open to feedback on some of these things if they want to iterate on AppCDS to make it more user-friendly? |
|
Sounds like something that could done automatically in a "post install hook", which Ruby installers would invoke (TruffleRuby used to have one). |
|
Hello 👋🏻 this idea is quite interesting to me, although I'm not an AppCDS expert (more of a user in this regard). Are you suggesting it could be useful to use such a post-install hook mechanism to trigger an (optimistic) initial dump of a cache post install with whatever the users install-time default JDK is, of some opinionated "hello world" that might cover a reasonable amount of JRuby's initial byte code to otherwise accelerate first-user-launch? Probably a little different to what we were trying to consider here which was more of "what to do/how to detect bad caches which the JVM cannot gracefully degrade from on its own". Unless what you are also suggesting is that the post install ran something to trigger a cache dump, then tried to use that dump and it fails for some reason (e.g with a sealing violation) then disables AppCDS "by default" for the user. If so, not sure how many "bad cache" situations that would detect. The edge case failures I've seen so far tend to be quite sensitive to exactly which code you try and run, args/params, classes tried to be loaded etc. |
|
Yeah I was thinking to just generate the AppCDS at post install, doing it later is far more tricky as the OP explains. |
|
I’m not sure thats possible on its own (for developer environments at least) since you can switch JVMs at any time independent of installation and a new cache would be needed. Doing at install time I don’t think wouldn’t have done anything to prevent the specific sealing violation issue referenced, which would have been triggered later on for any class whose entire package was not in the initial cache (which seems to me is almost certainly the case for one package or another?). it’s also unclear to me how to exercise enough code to generate a usefully scoped (and general purpose) cache at install time, although maybe it could be better than what you get if using something indeterminate where an installer might run a hello world of its own, triggering cache generation independent of a user's needs |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We currently generate an Application Class Data Store (AppCDS) file, cached in the current JRuby installation directory, when the
jrubycommand is first invoked. This can produce a bad CDS cache (or fail to start) in a number of situations:jruby -v, which loads very few classes for caching (bad cache).We are somewhat limited in detecting these situations, due to the requirement that we make cache decisions at the
javacommand. Most runtime failures due to a bad cache can't be detected until they have failed, raised errors, and terminated the process.I'm opening this discussion to talk through ideas.
The simplest answer would be to only generate the AppCDS cache when it is explicitly requested with
--cache. This would however require all users to know about the presence of this flag before they can get improved startup times.We could add more detection to the
jruby.shmaster script, such as scanning for non-empty directories inCLASSPATHor disabling automatic cache generation if any-Joptions have been passed. We can't detect all such problematic situations, though.See recent issues with AppCDS:
All reactions