RFR: JDK-8282798 java.lang.runtime.Carrier

John Rose john.r.rose at oracle.com
Tue Mar 8 20:44:13 UTC 2022


On 8 Mar 2022, at 11:53, Jim Laskey wrote:

>> I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ?

> Clarified the comment. You are right. When I reworked the original code I dropped the intermediate object. For my purposes, it was about performance. If the object needs to be protected then it's up to the client to protect.  The same would be true if I add byte[] for all binary carriers.

I would prefer protecting the Object[] inside a non-public-class envelope object.

It’s a performance hit, but only on a path (no class spun b/c a high number of components) where there is no detailed optimization strategy anyway.

For the less-optimized path, putting everything into an Object[] (boxing primitives as well?) suggests that performance (+ footprint) is not an issue anyway.  In that case, the extra cost of adding the envelope object (indirection cost + footprint) not be a unique cost.

The best reason to put an envelope around the Object[] array (or other user-crackable representation) is the same reason we randomize encounter order in Set.of and Map.of.  It’s extra work, but it prevents users from building in out-of-contract dependencies in their code.  If this API exposes Object[] values, even temporarily, is is possible (even likely) that users will notice and build in out-of-contract dependencies.  The sad result of “optimizing” the Object[] representation by omitting the envelope will be that further optimizations (real ones!) will be harder to get accepted.

Summary:  Put the envelope around the Object, on paths which use Object[].

Second suggestion, as a follow-on task for later, is add a long[] array into that same envelope and use the long[] array for all primitive values, instead of boxing them as Integer, Long, etc.  (Or put the long[] array as the first item in the Object[] array.)  It probably doesn’t matter, but 32-bit values could be stored in high or low halves of the long elements.  (I think I’m not the only one to prototype it that way; I’ll bet Remi did something similar.)


More information about the core-libs-dev mailing list