where to file hotspot bugs

[David Holmes]

Ulf Zibis said the following on 05/12/11 19:03:
> As Roger asked for where to file a bug, I think a complete Link would help:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044160
> (but wait 1 or 2 days)

Well to file a bug its:

http://bugreport.sun.com/bugreport/

but that's linked from the above. ;-)

Paul: you beat me to it :)

David

> -Ulf
> 
> Am 12.05.2011 09:27, schrieb Paul Hohensee:
>> I filed 7044160 for this.  It's supposed to show up externally within 
>> 24 hours.
>>
>> Paul
>>
>> On 5/11/11 8:20 PM, Dr Andrew John Hughes wrote:
>>> On 16:30 Wed 11 May     , roger hoover wrote:
>>>> I recently fixed a bug in Apple's Java SE 6 hotspot introduced by 
>>>> merging 6u25, and since open jdk7 has the same code I should 
>>>> probably note it somewhere by filing a bug.  While I could file it 
>>>> with MACOSX-PORT JIRA, it is not really mac specific.  Where should 
>>>> I be filing hotspot bugs?
>>>>
>>> Unfortunately, OpenJDK STILL doesn't have an active bug database.
>>> There is https://bugs.openjdk.java.net/ but no-one seems to use it or 
>>> fix the issues therein.
>>>
>>>> [for the curious, what follows are the details of the bug:]
>>>>
>>>> Back in 2005, Apple's performance team forced us to fix all memory 
>>>> leaks in Java.  One of these fixes was to argument processing at the 
>>>> end of bool Arguments::add_property(const char* prop):
>>>> Index: HotSpot/trunk/src/share/vm/runtime/arguments.cpp
>>>> ===================================================================
>>>> --- HotSpot/trunk/src/share/vm/runtime/arguments.cpp    (revision 
>>>> 13535)
>>>> +++ HotSpot/trunk/src/share/vm/runtime/arguments.cpp    (revision 
>>>> 13596)
>>>> @@ -813,4 +813,8 @@
>>>>     // Create new property and add at the end of the list
>>>>     PropertyList_unique_add(&_system_properties, key, value);
>>>> +  FreeHeap(key);
>>>> +  if (eq != NULL) {
>>>> +    FreeHeap(value);
>>>> +  }
>>>>     return true;
>>>>   }
>>>> Unfortunately, the hotspot in the 6u25 update makes a change that 
>>>> relies upon this leak.  (Note that PropertyList_unique_add copies 
>>>> key and value):
>>>> @@ -927,9 +992,7 @@
>>>>     } else if (strcmp(key, "sun.java.command") == 0) {
>>>>       _java_command = value;
>>>>
>>>> -    // don't add this property to the properties exposed to the 
>>>> java application
>>>> -    FreeHeap(key);
>>>> -    return true;
>>>> +    // Record value in Arguments, but let it get passed to Java.
>>>>     } else if (strcmp(key, "sun.java.launcher.pid") == 0) {
>>>>       // launcher.pid property is private and is processed
>>>>       // in process_sun_java_launcher_properties();
>>>>
>>>> I changed the apple version to allocate new space for _java_command, 
>>>> but in jdk7 all args that fall through to the end leak except for 
>>>> sun.java.command=command.
>>>>
>>> Do you have a patch for the issue?  I'd be interested in applying it
>>> to IcedTea for GNU/Linux users, even if Oracle are happy to let it
>>> slip through the cracks.
>>