Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE

[Joseph Provino]

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.

> 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
>