RFR(L): JDK-8057777 Cleanup of old and unused VM interfaces

[David Holmes]

Hi Fred,

Looks okay to me too. But I wouldn't be surprised if there is some test 
somewhere that checks for things when PrintJVMWarnings is set :)

David

On 7/10/2014 12:32 AM, Frederic Parain wrote:
> Thank you very much for catching the JVM_O_DELETE issue.
> I moved the O_DELETE support into the ZipFile.c file
> (code was the same for all non-Windows platforms) and
> cleaned up the original code in HotSpot.
>
> The new webrevs:
>
> http://cr.openjdk.java.net/~fparain/8057777/jdk_v03/
> http://cr.openjdk.java.net/~fparain/8057777/hotspot_v03/
>
> Regards,
>
> Fred
>
> On 10/03/2014 06:07 PM, Xueming Shen wrote:
>> On 10/3/14 8:19 AM, Alan Bateman wrote:
>>> On 30/09/2014 07:40, Hideric Parain wrote:
>>>> Hi all,
>>>>
>>>> Please review changes for bug JDK-8057777 "Cleanup of old
>>>> and unused VM interfaces"
>>>>
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8057777
>>>>
>>>> This is basically a big cleanup of VM interfaces that are
>>>> not used anymore by the JDK but have been kept in our code
>>>> base for historical reasons (HotSpot Express for instance).
>>>> These changesets remove these interfaces from both the
>>>> JDK and the HotSpot side, and also perform some cleanup
>>>> on code that directly referenced the removed interfaces.
>>>>
>>>> These changes do not modify the behavior of the Java
>>>> classes impacted by the cleanup.
>>>>
>>>> VM interfaces removal has been approved by CCC and
>>>> a Release Note has been prepared that explicitly list
>>>> all the removed interfaces.
>>>>
>>>> Testing: JPRT hotspot + core, vm.quick.testlist, jdk_core
>>>>
>>>> Webrevs:
>>>> http://cr.openjdk.java.net/~fparain/8057777/
>>> cc'ing core-libs-dev as part of this is clean-up in the library code
>>> too.
>>>
>>> I think we should deprecate java.lang.Compiler and the
>>> Runtime.traceXXX methods. They've been non-functional for a long time
>>> and having them in the API is a bit mis-leading to anyone reading the
>>> javadoc. I realize you are focused on the removing the old JVM_*
>>> functions so we can follow-up on that via other issues of course.
>>>
>>> Can ClassLoader#resolveClass0 can be removed completely? The null
>>> check can be done in ClassLoader#resolveClass.
>>>
>>> In the mapfile for libjava then the comment at line 281 says
>>> "ZipFile.c needs this one". As getLastErrorString is now exported for
>>> use by libzip then the comment should probably be updated.
>>>
>>> Otherwise this clean-up looks good to me and the jdk_core group of
>>> tests is the right group to exercise this area.
>>>
>>> -Alan
>>>
>>
>> Hi,
>>
>> ZipFile.c expects the JVM_Open() to handle the JVM_O_DELETE, with
>> explicit unlink on linux/solaris for example.
>> I would assume the open from the c library does not handle it and we
>> need to do it explicitly by ZipFile.c now?
>>
>> -Sherman
>>
>>
>