RFR: String Density/Compact String JEP 254 (update)

Xueming Shen xueming.shen at oracle.com
Sun Nov 1 19:12:44 UTC 2015


On 11/1/15 10:18 AM, Alan Bateman wrote:
> On 30/10/2015 21:30, Xueming Shen wrote:
>> Hi,
>>
>> Thanks for the comments/suggestions. Here are the updated webrevs 
>> with minor changes here
>> and there based on the feedback.
> I spent time going through the changes in jdk repo and it looks very 
> good.
>
> One thing that isn't clear to me is why StringUTF16 needs a native 
> method to test for big endian. Could it use Unsafe::isBigEndian or is 
> there a non-obvious bootstrapping/initialization issue here?

unsafe.putChar/getChar() were used in String (they are still being used 
in charset changes).

http://cr.openjdk.java.net/~sherman/8054307/jdk.1030/src/java.base/share/classes/java/lang/StringUTF16.java.html

However it triggered a vm failure in hotspot PIT, in which it appears 
the unsafe is not ready/loaded
at certain circumstance.

...results/workDir/demo/jvmti/heapTracker/HeapTrackerTest/hs_err_pid12542.log 


So we are back to the old approach to go get the endian ourselves.

>
> The additional test coverage looks quite good but I'm guessing many of 
> these tests overlap with existing tests. Are you planning to leave 
> them in the CompactStrings directory? I assume it would make more 
> sense to move them up to the String directory. I was also wondering if 
> more of the existing tests should be updated to run them both ways. In 
> passing, SerializationUtils has a semi-colon at L47 that looks a bit odd.
>
Yes, it might be worth to take some time to re-organize the String 
tests. We can address it in
a separate follow-up bug fix. Need take to the SQE team.

Thanks,
-Sherman





More information about the core-libs-dev mailing list