Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE

[Coleen Phillimore]

Joe,

I don't mind whichever way you fix 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/>

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