[aarch64-port-dev ] RFR (XS) JDK-8209586: AARCH64: SymbolTable changes throw assert on aarch64

[Gerard Ziemski]

Looks good.


cheers

> On Aug 16, 2018, at 10:30 AM, Stuart Monteith <stuart.monteith at linaro.org> wrote:
> 
> Thanks for looking at this Gerard, Coleen.
> 
> I'm sending this out with a new subject for a formal review. I've ran
> it successfully with tier1 tests.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209586
> 
> CR: http://cr.openjdk.java.net/~smonteith/8209586/webrev-cast/
> 
> This fix allow aarch64 debug builds to complete successfully.
> 
> Thanks,
>    Stuart
> 
> 
> On Thu, 16 Aug 2018 at 16:19, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>> 
>> hi Stuart,
>> 
>> Thank you for fixing this and apologies for messing it up for aarch64
>> 
>> (r)eviewed
>> 
>> 
>> cheers
>> 
>>> On Aug 16, 2018, at 9:02 AM, Stuart Monteith <stuart.monteith at linaro.org> wrote:
>>> 
>>> Hello,
>>> I brought my repository forward, and found that debug builds now
>>> fail on aarch64. I've raised JDK-8209586, the SymbolTable code assumes
>>> that the jbyte type is the same as the char type. jbyte is "signed
>>> char", whereas "char" is unsigned or signed. As it turns out, on
>>> aarch64 chars are unsigned.
>>> 
>>> A trivial fix is: http://cr.openjdk.java.net/~smonteith/8209586/webrev-cast/
>>> 
>>> I'm looking at whether it might be better to change instances of
>>> "char" to "signed char" or "jbyte".
>>> 
>>> Thanks,
>>>  Stuart
>>> On Mon, 30 Jul 2018 at 17:19, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>>> 
>>>> Please review this Enhancement, which uses the new concurrent hash table for SymbolTable.
>>>> 
>>>> This is an effort similar to the one behind JDK-8195097 "Make it possible to process StringTable outside safepoint” from a while ago.
>>>> 
>>>> The main expected goal here is to eliminate safepoint pauses needed to cleanup the table. This goal was achieved by using “Service Thread” to do the cleaning. Checking whether we need to clean is performed on “VM Thread”, after class unloading (we check the entire table). We also check the bucket into which we happen to be inserting a new item.
>>>> 
>>>> A few things to note:
>>>> 
>>>> - The SymbolTable implementation follows closely that of StringTable - we might be able to factor out common code later
>>>> 
>>>> - There are a few small, but statistically significant, regressions in startup benchmarks (around 2-5%) that will be addressed later, tracked by JDK-8208142
>>>> 
>>>> - There is an outstanding question about whether we can safely walk the table during a safepoint using do_scan, but without locking, tracked by JDK-8208462
>>>> 
>>>> - There is a cleanup opportunity presented now to remove rehashable hash table, tracked by JDK-8208519
>>>> 
>>>> - There is a new test that validates that we free dead entries when we insert new symbols (using short lived symbols via Class.forName() API)
>>>> 
>>>> 
>>>> Tested using Mach5 hs-tier1,2,3,4,5 (final test running right now…)
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~gziemski/8195100_rev1/
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195100
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>