slim-java: stop stripping .so files #537
Conversation
…adds ~4Mb Signed-off-by: Stewart X Addison <[email protected]>
|
Wouldn't the typical workflow be for someone to deploy a specialist debug image? |
|
Debug symbols are not necessary for profiling - no need for a full set of debug symbols for that, but you want to be able to see the names of the methods being invoked. I think the 5Mb overhead is well worth it to avoid a lot of extra hassle, particularly in a docker image (and up until recently we didn't produce such images for HotSpot, and even now it's also not something we easily make available even if people wanted to go to the hassle of downloading them into their docker images) |
|
Hmm, these are the slim images though which I think comes with an expectation that everything is stripped out. |
|
Playing devil's advocate here: When you opt for the slim image, you're opting for a weird "JDK but not really a JDK" experience. There are posts like An OpenJDK 14 Docker image that's 33% slimmer than Adoptium's, so people apparently want that. Why take it away? If somebody wants to have something that's blessed, they shouldn't take the slim images. |
|
If we cared that much about the size we might have responded to #478 as well. I don't know what people's motivations are when they pick the slim one, so while that /may/ be a valid response I don't think that 5Mb (~2%) necessarily tips the balance in favour of stripping them all (I was surpsied it wasn't more to be honest) but if that's the case we should definitely respond in the issue that this would "fix". I've had another discussion on this during the week on this topic so it may not immediately be obvious to people that we've restricted it this way. (EDIT: Also, having just looked at that "33% slimmer" image - it looks on a quick look that the JDK directory is about 280Mb so larger than our non-Alpine SLIM image, so if we wanted to reduce further there is almost certainly further opportunities) |
Just guessing here, but I assume this is rather caused by lack of development resources than anything else. I went through the old issues and PRs. Information about the use case and the promise around the slim images is hard to find. The current README offers this:
#29 (comment) offers some context in regards to a quality bar. Apparently, the objective is to pass headless TCK testing (I don't know what that requires). If not stripping .so files is required "while running in a cloud", add it. If "headless TCK testing" requires not to strip .so files, add it. Otherwise 🤷. |
I'm quite 🤷 on it too, and while I can totally understand why they were stripped, I'd now slightly err on the side of including them given the numbers inbolved.
Almost certainly, but if our end users of our product are raising them it would be good to give some sort of response, even if it's "help wanted to fix it" or a reason why we don't. |
|
I don't really care about what we do (strip or not), but we should set the expectations right.
I agree, but I cannot (and don't want to be) everywhere. |
|
The fact that we have a huge number of people using the slim images shows that they prefer having smaller sized images as this has a direct impact on docker push / pull times, provisioning times, build times (during CI/CD) etc. The whole point of the slim image has always been to solve this usecase. If people want full functionality they can always use the regular JDK/JRE images which dont have anything stripped out. Adding anything back into the slim images means it will fail the primary usecase and it is impossible to please everyone for individual scenarios. That being said, if we can reach broad agreement on what constitutes a slim image, we can make changes. Maybe we can have a poll on slack where folks can vote on this. In any case I would personally not want to merge this. |
Of course - if you have two images why not pick the smaller one? But there are people out there who do not realise that it has stripped out the symbols, making things like profiling in a live environment problematic, and that's something you may not find out until it's too late. I personall think 5MB or so is a price worth paying. Do we list anywhere what the expectations are of the slim image contents? https://hub.docker.com/r/adoptopenjdk/openjdk15-openj9 doesn't seem to make it clear what the differences are to end-users, so I don't think we can assume that the would necessarily expect those 5MB of symbols to be removed. If we don't merge this, we need to make it clear what the differences are. |
The size of JDK16 as included in the slim images is around 250Mb. Stripping the .so files makes it very hard to do any debugging/profiling on the JVM and only saves about 4-5Mb. this is probably not a good tradeoff, so I'm suggesting changing this.
Fixes #318 but has also been reported as a concern elsewhere
Signed-off-by: Stewart X Addison [email protected]