[9] RFR(S): 8040085: dtrace/jsdt tests crash on solaris. found an unadvertised bad scavengable oop in the code cache
Albert
albert.noll at oracle.com
Tue Apr 29 05:29:44 UTC 2014
Hi Chris,
thanks for looking at this. Unfortunately, the change is already pushed.
Shall I file a new bug for adding the code you proposed? Alternatively,
we could also do the change when fixing:
https://bugs.openjdk.java.net/browse/JDK-8022968
I would update the bug accordingly.
What do you think?
Best,
Albert
On 04/28/2014 09:46 PM, Christian Thalinger wrote:
> Not sure if this was pushed already but you should do something like
> AdapterHandlerLibrary::create_native_wrapper to print compilation and
> handle a full code cache:
>
> // Install the generated code.
> if (nm != NULL) {
> if (PrintCompilation) {
> ttyLocker ttyl;
> CompileTask::print_compilation(tty, nm, method->is_static() ?
> "(static)" : "");
> }
> nm->post_compiled_method_load_event();
> } else {
> // CodeCache is full, disable compilation
> CompileBroker::handle_full_code_cache();
> }
>
> Perhaps without the load event.
>
> On Apr 24, 2014, at 10:40 PM, Albert <albert.noll at oracle.com
> <mailto:albert.noll at oracle.com>> wrote:
>
>> Hi Roland,
>>
>> thanks for your quick response. Here is the updated webrev that keeps
>> the print().
>>
>> http://cr.openjdk.java.net/~anoll/8040085/webrev.02/
>> <http://cr.openjdk.java.net/%7Eanoll/8040085/webrev.02/>
>>
>> Best,
>> Albert
>>
>> On 04/25/2014 10:27 AM, Roland Westrelin wrote:
>>>> Here is a new webrev, which includes the clean-up.
>>>> http://cr.openjdk.java.net/~anoll/8040085/webrev.01/
>>> I think we still want the:
>>>
>>> tty->print("--- n “);
>>>
>>> part to match the PrintCompilation output for other methods (it
>>> doesn’t really match anymore, actually).
>>>
>>> Roland.
>>>
>>>> Best,
>>>> Albert
>>>>
>>>> On 04/25/2014 09:59 AM, Roland Westrelin wrote:
>>>>>> 7017732 was pushed 3 years ago. What does this show up now? Also,
>>>>>> CodeCache::add_scavenge_root_nmethod() is required if the nmethod
>>>>>> embeds oops but I don’t see where in
>>>>>> SharedRuntime::generate_dtrace_nmethod() we have constant oops.
>>>>> I took a look and found that the oop comes from:
>>>>>
>>>>> // Add the class loader of Method* for the nmethod itself
>>>>> append_oop_references(&oops, mh->method_holder());
>>>>>
>>>>> in finalize_oop_references() that is called from
>>>>> nmethod::new_dtrace_nmethod()
>>>>>
>>>>> So Albert’s fix look good to me.
>>>>>
>>>>> I also noticed this in AdapterHandlerLibrary::create_dtrace_nmethod():
>>>>> if (PrintCompilation) {
>>>>> ttyLocker ttyl;
>>>>> tty->print("--- n%s ");
>>>>>
>>>>> %s but no argument passed. Can you clean that up as well, Albert?
>>>>>
>>>>> Roland.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140429/f92060d6/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list