RFR: 8221724: Enable archiving of Strings with hash 0

[Ioi Lam]

Hi Claes,

The changes look good.

On 4/1/19 6:12 AM, Claes Redestad wrote:
> Hi,
>
> the current implementation of String archiving explicitly excludes
> Strings with hashcode 0, including "". The reason for this is not
> explicitly stated, but is likely to be due the fact that
> String::hashCode currently stores the calculated 0 to String.hash every
> time, which doesn't play well with read-only memory.
>
Actually, archived strings are not stored in read-only memory. Instead, 
the pages are mmap'ed copy-on-write. So for a non-empty archive string S 
with zero hashcode, if you call S.hashCode, with your patch on top of 
the current JDK code, we will end up writing a zero to S.hash (which was 
zero to begin with). The net effect is no changes in memory content, but 
the page does get dirtied, and will no longer be sharable with other 
processes that map the same CDS archive.

When your other patch JDK-8221723 is applied with this patch (8221724), 
then we will no longer have any dirty pages when you call S.hashCode for 
any archived string S.

Thanks
- Ioi


> This behavior is a blocker for archiving things where such strings might
> exist and there is code depending on the identity of the same, so I
> propose dropping this restriction. This doesn't _break_ anything
> functionally: all tests passes with this patch, regardless of whether
> the patch I'm proposing to change String::hashCode is applied, but some
> pages could be dirtied and copied into non-shared memory.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8221724
> Webrev: http://cr.openjdk.java.net/~redestad/8221724/open.00/
>
> Testing: tier1-3
>
> Thanks!
>
> /Claes
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8221723