Request for reviews (XS): 6925573: vm/classfmt/lmt/mthnum001/mthnum00101m1/mthnum00101m1.html hangs since JDK7-b72 (-d64, solaris)

[Volker Simonis]

I've implemented the two specialized compare functions for narrow oops
as requested. I've also updated the webrev with some absolute time
measurements for the loading of a class with 60000 methods on
Solaris/SPARC. Please see:

http://www.progdoc.de/webrev/6925573.v2/

Reagrds,
Volker

PS: having two versions of the idempotent function is indeed a little
bit ugly. I tried to solve it with a template function but
unfortunately the compare functions have to be "extern C" because they
are called from qsort, so we can't use templates. It's probably not
worth thinking about it any more...

On Mon, May 3, 2010 at 7:36 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>
> On May 3, 2010, at 10:29 AM, Coleen Phillimore wrote:
>
>>
>> Volker,
>> Thank you for fixing this!  It was on my list but I hadn't gotten to it yet.
>>
>> I thought that we'd want to have a special narrow_oop_compare_fn() so that we don't have to test if (UseCompressedOops) for each comparison, but your testing shows no penalty for the frequent global value test.
>
> I'd considered the same issue but you'd also need method_compare_narrow_idempotent which uglies it up a bit.  It would be nicer in some ways though.
>
> tom
>
>>  To be clear though,  in your table, the -UseCompressedOops case was before your fix?  If so, your fix looks great, and I'd be happy to check it in after another review.
>>
>> Thanks,
>> Coleen
>>
>> On 05/03/10 12:57, Volker Simonis wrote:
>>> Hi,
>>>
>>> I fixed 6925573 which was caused by the Compressed Oops change which
>>> changed the method sorting algorithm for class methods during
>>> classloading from quicksort to bubblesort.
>>>
>>> Could somebody please review the change at
>>>
>>> http://www.progdoc.de/webrev/6925573/
>>>
>>> and submit it if is deemed to be suitable.
>>>
>>> Thanks,
>>> Volker
>>>
>>
>
>