Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE

[Coleen Phillimore]

On 11/15/2013 12:55 PM, David Holmes wrote:
> Hi Joe,
>
> On 16/11/2013 3:11 AM, Joseph Provino wrote:
>>
>> On 11/15/2013 11:56 AM, Coleen Phillimore wrote:
>>>
>>> Joe,
>>>
>>> I don't mind whichever way you fix
>>
>> Coleen, I'm happy to fix it whichever way is determined to be best.
>
> Given this has to get special approval at this stage lets go with your 
> JVMTI_RETURN proposal. We can look at how to make this generally more 
> robust for 8u or 9.

This is fine, I reviewed it too.
Coleen

>
> Thanks,
> David
>
>>> it but there's another similar instance coming in bug, that you might
>>> want to wait for.
>>>
>>> RFR: 8027630 SIGSEGV in const char*Klass::external_name()
>>> http://cr.openjdk.java.net/~sla/8027630/webrev.00/
>>> <http://cr.openjdk.java.net/%7Esla/8027630/webrev.00/>
>>
>> I don't mind waiting but does this change need a "guard".  It's in
>> threadServices.* which is always included (I think).
>>
>> joe
>>
>>>
>>> Coleen
>>>
>>> On 11/14/2013 11:45 PM, David Holmes wrote:
>>>> Hi Joe,
>>>>
>>>> On 15/11/2013 6:35 AM, Joseph Provino wrote:
>>>>>
>>>>> webrev is here:
>>>>>
>>>>> http://cr.openjdk.java.net/~jprovino/8028396/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Ejprovino/8028396/webrev.00/>
>>>>
>>>> As per other email I think the more appropriate fix here is to guard
>>>> the callsite in MetadataOnStackMark as JVMTI_ONLY:
>>>>
>>>> JVMTI_ONLY(JvmtiCurrentBreakpoints::metadata_do(Metadata::mark_on_stack)); 
>>>>
>>>>
>>>>
>>>> Any code that uses an optional facility, like JVMTI or other GC or
>>>> tracing etc, has to guard that use. It would probably be better if
>>>> there was also guards in the jvmtiImpl.hpp file so that this issue
>>>> would have been detected at build time. I know this isn't necessarily
>>>> trivial because we have to retain sufficient parts of JVMTI to
>>>> provide the base API that can report that JVMTI functionality is not
>>>> available - but I don't think JvmtiCurrentBreakPoints falls into that
>>>> category.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> thanks.
>>>>>
>>>>> joe
>>>
>>