Add a getImplementationName method to VectorizationProvider that returns the name of the selected implementation #15294
Conversation
…rns the name of the selected implementation
| } | ||
|
|
||
| public void testGetProviderName() { | ||
| assertEquals("DefaultVectorizationProvider", VectorizationProvider.getImplementationName()); |
There was a problem hiding this comment.
This is all makes sense to me, but I'm wondering under what circumstances we would have an alternate provider and whether we can test that. Is that something that only happens in the MRJAR code? If that's right, do we have MRJAR-specific tests where we could test that this also works when we have a non-default provider?
There was a problem hiding this comment.
You mean, under what circumstances we could get VectorizationProvider.getImplementationName() return something other than DefaultVectorizationProvider (and thus, make the test fail?). If so, I was thinking something along those lines too, like, if someone runs the tests with the right conditions, this could return the Panama implementation and make the test fail.
I guess an option to handle this case is to relax the test and make the return name be any of the existing implementations. Still, not ideal because it would break in the future if a new implementation is added but not included in this list. We could make the test more complex by looking for all implementations dynamically, but at that point we aren't testing anything that valuable and the test becomes way more complex than the code itself.
Is that what you were thinking? or did I misunderstood your comment?
There was a problem hiding this comment.
Yes, the value that gets used will currently either be DefaultVectorizationProvider or PanamaVectorizationProvider - The Panama one gets used when the JDK is new enough and the CPU preferred vector size can handle it ... the logic is in VectorizationProvider. So this test will pass or fail depending on the host and JDK used to run it. Although since we require JDK version in the build I think that will be guaranteed to support. But we probably would need to add some kind of assumeTrue so the test doesn't fail on architectures that do or don't support the level of Panama we require.
I'm actually surprised this test passed for you and on github - I would have expected the result to be PanamaVectorizationProvider for most setups?
There was a problem hiding this comment.
But we probably would need to add some kind of assumeTrue
ah, yes, that's a good idea
I'm actually surprised this test passed for you and on github - I would have expected the result to be PanamaVectorizationProvider for most setups?
I guess the build system isn't adding the incubator vectorization module?
There was a problem hiding this comment.
Yeah I'm not clear how we are testing the Panama support -- we must be! I also get confused about whether the incubating flag is required - some Paname stuff finally came out of incubator? But I guess the Vector API is still in it and will be forever. But anyway we must somewhere be running tests with incubus unleashed
2 participants
Description
This draft is a possible solution for #15292. I implemented the
getName()as the simple class name, but could also be just a string that represents the class, likedefault/panama.With this new method, the initialization of the
Holder.INSTANCEcould happen from a caller that's not in theVALID_CALLERS. It would not be returned though, I'm not sure if that's a problem. getInstance would still require valid callers.An alternative approach could be to refactor the
lookupmethod in a way that thegetImplementationNamecould use to determine the implementation without actually initializing it.