Review request: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE

[David Holmes]

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.

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