S RFR: 8010783: assert(s->refcount() !=0) failed

[Daniel D. Daugherty]

Thanks for the additional info!

Thumbs up on the fix!

Dan


On 5/1/13 3:14 PM, Karen Kinnear wrote:
> Dan,
>
> Thank you for the quick review. I updated the bug to answer the concern you brought up
> from Vladimir.
>
> To repeat it here:
>
> Default methods are new with JDK8. They are concrete methods in interfaces.
> The intention is to be able to expand existing interfaces with new methods, without
> requiring recompilation of older classfiles. If any supertype has a default method, then
> you will check for defaults in a given class in order to apply the new inheritance rules
> for concrete methods in interfaces, which are designed to prevent multiple inheritance -
> i.e. any method defined in a superclass wins, otherwise if there is a unique most-specific
> default method you use that. Any ambiguity throws and error when you try to reference it.
>
> I put some of the highlights of the call stack in the bug report.
>
> As javac, the lambda metafactory and the addition of lambdas and new default methods
> in our libraries change rapidly in the near future, the vm will be processing more and more
> default methods.
>
> hope this helps,
> Karen
>
> On May 1, 2013, at 3:42 PM, Daniel D. Daugherty wrote:
>
>> On 5/1/13 1:26 PM, Karen Kinnear wrote:
>>> Please review for lambda:
>>>
>>> http://cr.openjdk.java.net/~acorn/8010783/webrev/src/share/vm/classfile/bytecodeAssembler.cpp.sdiff.html
>> src/share/vm/classfile/bytecodeAssembler.cpp
>>     Swapping the order of the 'symbol_at_put()' and 'increment_refcount()'
>>     calls is simple enough. That should make this assert() happy:
>>
>>     src/share/vm/oops/constantPool.hpp:
>>     308    void symbol_at_put(int which, Symbol* s) {
>>     309      assert(s->refcount() != 0, "should have nonzero refcount");
>>
>>     by making sure the entry is marked as in-use before it is 'put'
>>     somewhere.
>>
>>     However, Vladimir's comment and the stack trace in the bug report
>>     made me wonder if we were doing some default method processing on
>>     classes that didn't need it. Perhaps there are two issues here?
>>
>> Thumbs up, if we don't have two bugs here.
>>
>> Dan
>>
>>> Passes test in bug report for fastdebug: java -XX:+CompileTheWorld -XX:+CompileTheWorldStartAt=12
>>> -Xbootclasspath/p:interclient-core.jar
>>>
>>> vm.quick.testlist, lang, vm jck's in progress on on linux-x64
>>>
>>> thanks,
>>> Karen