RFR: 8207263: Store the Configuration for system modules into CDS archive

[Claes Redestad]

Hi,

Jiangli and I discussed a subtle issue with the archiving changes here 
last week (she's currently on vacation, and I was at JVMLS this week, so 
it was never brought to the list, sorry!)

Basically: the empty configuration uses things like 
Collections.emptySet(), which means it will end up deserializing an 
object from the archive that doesn't (necessarily) have the same 
identity as the object retrieved from direct uses of Collection.emptySet().

Same goes for the Set.of()/Map.of()/List.of() singletons which might now 
already exist at runtime in two versions since the change to archive 
ModuleDescriptors. Oops!

This glitch is probably fine semantically for most intents and purposes, 
but could lead to some unnecessary inefficiencies and theoretically real 
surprises/bugs, so we probably need to ensure that all singletons we 
serialize retain the property that they are identical to the object a 
caller of the respective getter would receive.

I think this can be deferred to a must-fix follow-up, mainly since 
there's some benefit in first cleaning up a few things here first:

- currently we have uses of both Collections.emptyFoo() and Foo.of() in 
the ModuleDescriptor/Configuration code

- to be correct, we thus need to archive the Collections.emptyFoo() 
singletons *and* the various java.util.ImmutableCollections ones

- if we first consolidated all uses of Collections.emptyFoo() to 
Foo.of() (in java.lang.module), we'd only need to archive the immutable 
singletons in java.util.ImmutableCollections

Consolidating to Foo.of() was actually already being considered anyway, 
so I'll go ahead with a separate RFE..

Thanks!

/Claes


On 2018-07-20 20:31, Jiangli Zhou wrote:
>
>
> Many thanks to Alan and Claes for discussions and contributions to 
> this change!
>
> Webrev: http://cr.openjdk.java.net/~jiangli/8207263/webrev.00/