On Tue, 19 Nov 2024 07:06:15 GMT, David Holmes wrote:
>> There was an extern trace_class_resolution() function that called this _impl
>> function that I removed, so renamed this impl function to
>> trace_class_resolution().
>> It's declared extern in jvm.hp file, and this 'extern' qualifier is
On Mon, 18 Nov 2024 03:00:36 GMT, David Holmes wrote:
>> jni.cpp functions call this.
>
> I don't see any difference in the callers in relation to this PR and the
> function is not presently declared `extern`. ??
There was an extern trace_class_resolution() function that called this _impl
func
On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote:
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does
On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer
On Sat, 16 Nov 2024 03:22:01 GMT, John R Rose wrote:
>> src/hotspot/share/prims/jvm.cpp line 169:
>>
>>> 167: while (!vfst.at_end()) {
>>> 168: Method* m = vfst.method();
>>> 169: if
>>> (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass()))
>>> {
>>
On Sat, 16 Nov 2024 02:41:59 GMT, John R Rose wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains nine commits:
>>
>> - Handle merge conflicts in new resolve_instance_class c
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
On Thu, 14 Nov 2024 05:45:48 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Purge last references to SecurityManager.
>
> src/hotspot/share/classfile/di
On Thu, 14 Nov 2024 14:42:30 GMT, Alan Bateman wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More obsolete code. Fix trace_class_resolution (doesn't throw exception -
>>
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
On Thu, 14 Nov 2024 13:40:22 GMT, Coleen Phillimore wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer does
>> anything.
>>
On Thu, 14 Nov 2024 13:02:22 GMT, Coleen Phillimore wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does anything.
>
> Tested with tier1-4.
Coleen Phillimore has u
On Thu, 14 Nov 2024 05:42:51 GMT, David Holmes wrote:
>> Remove Hotspot code that passes protection_domain around class loading so
>> that checkPackageAccess can be called and the result stored. With the
>> removal of the Security Manager in JEP 486, this code no longer does
>> anything.
>>
On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote:
> Do you plan a follow-up to purge the remaining refs to AccessController and
> AccessControlContext?
I was unclear if they were still needed in the places they appear. Maybe I
should do a follow-up.
-
PR Comment: https://git
On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote:
> Remove Hotspot code that passes protection_domain around class loading so
> that checkPackageAccess can be called and the result stored. With the
> removal of the Security Manager in JEP 486, this code no longer does
On Thu, 24 Oct 2024 07:15:53 GMT, Alan Bateman wrote:
>> but you won't see access_controller_klass or priviledged_action_klass
>> frames, so no need to skip them? Not sure why you'd want to skip class
>> loader frames here.
>
> Right, although you might have to wait until there is more cleanup
On Wed, 23 Oct 2024 12:53:12 GMT, Alan Bateman wrote:
>> src/hotspot/share/prims/jvm.cpp line 1272:
>>
>>> 1270:
>>> 1271:
>>> 1272: // Returns the inherited_access_control_context field of the running
>>> thread.
>>
>> There's some code in this file in
>> static void trace_class_resolution
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote:
> This is the implementation of JEP 486: Permanently Disable the Security
> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
> main change
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote:
> Remove trailing "blank" lines in source files.
>
> I like to use global-whitespace-cleanup-mode, but I can not use it if the
> files are "dirty" to begin with. This fix will make more files "clean". I
> also considered adding a check for t
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote:
> Remove trailing "blank" lines in source files.
>
> I like to use global-whitespace-cleanup-mode, but I can not use it if the
> files are "dirty" to begin with. This fix will make more files "clean". I
> also considered adding a check for t
On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth wrote:
> Remove trailing "blank" lines in source files.
>
> I like to use global-whitespace-cleanup-mode, but I can not use it if the
> files are "dirty" to begin with. This fix will make more files "clean". I
> also considered adding a check for t
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted t
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted t
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted t
This change removes the last remnants of sun/hotspot/WhiteBox.java and other
classes, and uses the versions in jdk/test/whitebox.
I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
deleted the old files and some references to sun.hotspot.
Tested with tier1-4.
---
On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote:
> This change uses sed to change sun.hotspot.WhiteBox to
> jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to
> indirect inclusions of some of the test libraries, changing a few wasn't a
> relia
On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore wrote:
> This change uses sed to change sun.hotspot.WhiteBox to
> jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to
> indirect inclusions of some of the test libraries, changing a few wasn't a
> relia
On Fri, 8 Jul 2022 06:12:18 GMT, David Holmes wrote:
>> This change uses sed to change sun.hotspot.WhiteBox to
>> jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to
>> indirect inclusions of some of the test libraries, changing a few wasn't a
>> reliable option, and I need
This change uses sed to change sun.hotspot.WhiteBox to
jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly. Due to
indirect inclusions of some of the test libraries, changing a few wasn't a
reliable option, and I need the new one for a different change I was looking at.
The non-sed c
36 matches
Mail list logo
