Re: RFR: 8227587: Add internal privileged System.loadLibrary
On 16/07/2019 14:48, Claes Redestad wrote:
Hi,
refactored to use a BootLoader::loadLibrary API that is only visible
within the java.base module:
http://cr.openjdk.java.net/~redestad/8227587/open.03/
I've retained the bridge to ClassLoader::loadLibrary for performance,
but without any magic or privilege escalation involved. Moving sys_path
/ systemNativeLibraries out of ClassLoader seems quite complicated, so
I've not attempted that refactoring for this RFE
Adding BootLoader.loadLibrary is okay but we should try to keep method
description consistent with the other methods in this class. Also I
think we can clean up the SM path while we are there.
Several of the NIO classes have been changed to the following, which
looks a bit odd
jdk.internal.loader.BootLoader.loadLibrary("net");
jdk.internal.loader.BootLoader.loadLibrary("nio");
I see this has been pushed so I'll create a follow-on issue for the
cleanups.
-Alan.
Re: RFR: 8227587: Add internal privileged System.loadLibrary
On 7/17/19 3:25 AM, Claes Redestad wrote: Hi Peter, On 2019-07-17 10:29, Peter Levart wrote: Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls to initializePath() in the if block of ClassLoader.loadLibrary() are wrapped with a single doPrivileged(), you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in BootLoader. And since initializePath() would only be called once and then the results cached, you end up with less doPrivileged() wrappings when SecurityManager is present as soon as BootLoader.loadLibrary is called the 2nd time. hmm, fromClass.getClassLoader() also does a security check, though. Class::getClassLoader is caller-sensitive and the call to fromClass.getClassLoader() does not trigger any security permission check as it's called from NativeLibrary who is loaded by the boot loader. That said, there's a case for wrapping the initializePath calls in a doPriv of their own, since we now have an implicit requirement that some system library is loaded first (so that sys_paths is initialized) before any user code attempts to load a library of their own... I created https://bugs.openjdk.java.net/browse/JDK-8228336 to track the idea to refactor the system native library loading to BootLoader. I also have JDK-8228336 capturing Peter's observation. BTW, there is a data race when accessing usr_paths and sys_paths static fields in multi-threaded scenario. Their type is String[] which means that the contents of the arrays could be observed uninitialized (elements being null) in some thread. Both fields should be made volatile (not only sys_paths) as assignment to them can be performed more than once in idempotent racy initialization. .. and we typically seem to be loading at least one library before initializing any user code, which is probably why this has never been an issue. It seems like a good idea to remove this subtle fragility, though. I wonder if we shouldn't "simply" initialize the two paths during bootstrap and put them in final fields. JDK-8228336 tracks this. Mandy
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi Peter, On 2019-07-17 10:29, Peter Levart wrote: Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls to initializePath() in the if block of ClassLoader.loadLibrary() are wrapped with a single doPrivileged(), you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in BootLoader. And since initializePath() would only be called once and then the results cached, you end up with less doPrivileged() wrappings when SecurityManager is present as soon as BootLoader.loadLibrary is called the 2nd time. hmm, fromClass.getClassLoader() also does a security check, though. That said, there's a case for wrapping the initializePath calls in a doPriv of their own, since we now have an implicit requirement that some system library is loaded first (so that sys_paths is initialized) before any user code attempts to load a library of their own... BTW, there is a data race when accessing usr_paths and sys_paths static fields in multi-threaded scenario. Their type is String[] which means that the contents of the arrays could be observed uninitialized (elements being null) in some thread. Both fields should be made volatile (not only sys_paths) as assignment to them can be performed more than once in idempotent racy initialization. .. and we typically seem to be loading at least one library before initializing any user code, which is probably why this has never been an issue. It seems like a good idea to remove this subtle fragility, though. I wonder if we shouldn't "simply" initialize the two paths during bootstrap and put them in final fields. These are pre-existing issues though, so I think I'll take my reviews and push this enhancement for now. :-) Thanks! /Claes Regards, Peter On 7/16/19 3:48 PM, Claes Redestad wrote: Hi, refactored to use a BootLoader::loadLibrary API that is only visible within the java.base module: http://cr.openjdk.java.net/~redestad/8227587/open.03/ I've retained the bridge to ClassLoader::loadLibrary for performance, but without any magic or privilege escalation involved. Moving sys_path / systemNativeLibraries out of ClassLoader seems quite complicated, so I've not attempted that refactoring for this RFE. /Claes On 2019-07-12 20:03, Mandy Chung wrote: Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader. sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader. This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: Claes, Thanks for exploring this. I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library. No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use. It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar.
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi Claes, Am I reading correct that package-private ClassLoader.loadLibrary(Class fromClass, String name, boolean isAbsolute) wouldn't need to consult SecurityManager wasn't it for accessing system properties in private ClassLoader.initializePath(String propName). So perhaps if the two calls to initializePath() in the if block of ClassLoader.loadLibrary() are wrapped with a single doPrivileged(), you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in BootLoader. And since initializePath() would only be called once and then the results cached, you end up with less doPrivileged() wrappings when SecurityManager is present as soon as BootLoader.loadLibrary is called the 2nd time. BTW, there is a data race when accessing usr_paths and sys_paths static fields in multi-threaded scenario. Their type is String[] which means that the contents of the arrays could be observed uninitialized (elements being null) in some thread. Both fields should be made volatile (not only sys_paths) as assignment to them can be performed more than once in idempotent racy initialization. Regards, Peter On 7/16/19 3:48 PM, Claes Redestad wrote: Hi, refactored to use a BootLoader::loadLibrary API that is only visible within the java.base module: http://cr.openjdk.java.net/~redestad/8227587/open.03/ I've retained the bridge to ClassLoader::loadLibrary for performance, but without any magic or privilege escalation involved. Moving sys_path / systemNativeLibraries out of ClassLoader seems quite complicated, so I've not attempted that refactoring for this RFE. /Claes On 2019-07-12 20:03, Mandy Chung wrote: Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader. sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader. This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: Claes, Thanks for exploring this. I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library. No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use. It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
On 7/16/19 6:48 AM, Claes Redestad wrote: Hi, refactored to use a BootLoader::loadLibrary API that is only visible within the java.base module: http://cr.openjdk.java.net/~redestad/8227587/open.03/ Looks good. Nit: in JavaLangAccess 321 void loadLibrary(Class klass, String library); s/klass/caller/ I've retained the bridge to ClassLoader::loadLibrary for performance, but without any magic or privilege escalation involved. Moving sys_path / systemNativeLibraries out of ClassLoader seems quite complicated, so I've not attempted that refactoring for this RFE. Yes, it is non-trivial. I will file a RFE for this possible clean up. Mandy
Re: RFR: 8227587: Add internal privileged System.loadLibrary
> On 16 Jul 2019, at 14:48, Claes Redestad wrote: > > Hi, > > refactored to use a BootLoader::loadLibrary API that is only visible > within the java.base module: > > http://cr.openjdk.java.net/~redestad/8227587/open.03/ I think that this is good Claes. Reviewed. -Chris.
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi, refactored to use a BootLoader::loadLibrary API that is only visible within the java.base module: http://cr.openjdk.java.net/~redestad/8227587/open.03/ I've retained the bridge to ClassLoader::loadLibrary for performance, but without any magic or privilege escalation involved. Moving sys_path / systemNativeLibraries out of ClassLoader seems quite complicated, so I've not attempted that refactoring for this RFE. /Claes On 2019-07-12 20:03, Mandy Chung wrote: Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader. sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader. This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: Claes, Thanks for exploring this. I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library. No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use. It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader. sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader. This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: Claes, Thanks for exploring this. I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library. No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use. It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Claes, Thanks for exploring this. I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library. No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use. It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi, I'm dropping the java.desktop changes, and Mandy has asked me to explore options that does not add a new @CallerSensitive entry point, even to a strongly encapsulated API like JavaLangAccess Easiest of these is to explicitly provide the class context we're calling from - with proper assertions. This is marginally more performant due avoiding the Reflection.getCallerClass, but slightly less convenient. http://cr.openjdk.java.net/~redestad/8227587/open.01/ /Claes On 2019-07-12 15:27, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi, Regarding all the touches on the desktop module 1) awt-dev isn't the only list, you should have included swing-dev and 2d-dev at least 2) I am wondering what client testing you propose to do to verify this ? 3) I've spent spare time over a number of months trying to decrease unnecessary coupling between desktop and base modules. This seems to create additional technical debt there with minimal benefit, so in other words I'd much prefer that either you don't do this at all or the many, many, uses in the desktop module that are the heaviest Java->native code user in the JDK are dealt with entirely separately (separate bug) and at a minimum there is one place in the desktop module that they all call to and perhaps only then *through*. So do not push this. -phil. On 7/12/19, 6:27 AM, Roger Riggs wrote: Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: Hi Claes, JavaLangAccess.java: 316: Add @param tag done. System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes
Re: RFR: 8227587: Add internal privileged System.loadLibrary
Hi Claes, JavaLangAccess.java: 316: Add @param tag System.java: 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Roger On 7/11/19 9:43 AM, Claes Redestad wrote: Hi, by adding a method to load libraries with privileges to JavaLangAccess, we can simplify a slew of places where we are currently implementing adhoc privileged actions. This is a tiny but measurable gain on a range of startup tests. Webrev: http://cr.openjdk.java.net/~redestad/8227587/open.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8227587 Testing: tier1-3 Thanks! /Claes
RFR: 8227587: Add internal privileged System.loadLibrary
Hi, by adding a method to load libraries with privileges to JavaLangAccess, we can simplify a slew of places where we are currently implementing adhoc privileged actions. This is a tiny but measurable gain on a range of startup tests. Webrev: http://cr.openjdk.java.net/~redestad/8227587/open.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8227587 Testing: tier1-3 Thanks! /Claes
