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 12:39:32 GMT, Coleen Phillimore wrote:
>> 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
> function that I removed, s
On Fri, 15 Nov 2024 12:04:37 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvm.cpp line 154:
>>
>>> 152: */
>>> 153:
>>> 154: extern void trace_class_resolution(Klass* to_class) {
>>
>> why `extern` ?
>
> jni.cpp functions call this.
I don't see any difference in the callers in rel
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 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 does
>> anything.
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 does
>> anything.
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 calls.
>> - Merge branch 'maste
> 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 updated the pull r
On Fri, 15 Nov 2024 23:43:33 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
>> anything.
On Sat, 16 Nov 2024 02:48:09 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 calls.
>> - Merge branch 'maste
On Fri, 15 Nov 2024 23:43:33 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
>> anything.
On Fri, 15 Nov 2024 23:43:33 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
>> anything.
> 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 updated the pull r
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 -
>> shouldn't take TRAPS).
>
> I see a
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/dictionary.cpp line 80:
>
>> 78:
>> 79
On Thu, 14 Nov 2024 16:02:56 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
>> anything.
On Thu, 14 Nov 2024 07:53:32 GMT, David Holmes wrote:
> > > To be fair I'm unclear what role PD still plays on the JDK side and would
> > > not be surprised if it is destined for removal at some point.
> >
> >
> > PD is not deprecated as PD::getCodeSource is widely used. It may be that an
> >
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 -
>> shouldn't take TRAPS).
>
> I see a
> 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 updated the pull r
> 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 updated the pull r
On Thu, 14 Nov 2024 14:03:50 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
>> anything.
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 does
>> anything.
> 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 updated the pull r
On Thu, 14 Nov 2024 13:20:23 GMT, Alan Bateman wrote:
>> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env);
>>
>> I think this is obsolete too.
>
>> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env);
>>
>> I think this is obsolete too.
>
> As part of the JEP 486 work, I c
On Thu, 14 Nov 2024 13:07:55 GMT, Coleen Phillimore wrote:
> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env);
>
> I think this is obsolete too.
As part of the JEP 486 work, I changed SecurityManager::getClassContext to use
StackWalker, the native method that called into JVM_GetCla
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 does
>> anything.
> 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 updated the pull r
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 anything.
>
> T
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 anything.
>
> T
On Thu, 14 Nov 2024 07:01:54 GMT, Alan Bateman wrote:
> > To be fair I'm unclear what role PD still plays on the JDK side and would
> > not be surprised if it is destined for removal at some point.
>
> PD is not deprecated as PD::getCodeSource is widely used. It may be that an
> alternative me
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 anything.
>
> T
On Thu, 14 Nov 2024 06:16:56 GMT, David Holmes wrote:
> To be fair I'm unclear what role PD still plays on the JDK side and would not
> be surprised if it is destined for removal at some point.
PD is not deprecated as PD::getCodeSource is widely used. It may be that an
alternative means is in
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 anything.
>
> T
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 anything.
>
> T
38 matches
Mail list logo
