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

[Frederic Parain]

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

-- 
Frederic Parain - Oracle
Grenoble Engineering Center - France
Phone: +33 4 76 18 81 17
Email: Frederic.Parain at oracle.com