On 7/02/2016 4:27 AM, Peter Levart wrote:
On 02/06/2016 01:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortunately java system
classes aren't.
It doesn't seem so. At least, I can't find where main thread locks the
0x040ebee8 monitor:
"Thread-1":
waiting to lock
On 6/02/2016 10:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortunately java system classes
aren't.
The security manager has a lot of dependencies on other code/classes and
so requires lots of additional classloading to execute as desired. When
the SM is itself used
On 02/06/2016 01:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortunately java system
classes aren't.
It doesn't seem so. At least, I can't find where main thread locks the
0x040ebee8 monitor:
"Thread-1":
waiting to lock monitor 0x142766ac (object 0x040ebee8, a [
Hello!
PS> I still disagree and pushing back on the support for splitting
PS> after partial traversal. It’s not a pattern i think we should
PS> encourage and propagate so such behaviour can be generally relied
PS> upon, and predominantly for edge cases. That’s where the
PS> complexity string is be
The security manager is non blocking, unfortunately java system classes
aren't.
The policy provider in use thread confines PermissionCollection
instances, which never leave the cpu cache, they are discarded
immediately after use.
The problem here is that two different threads are attempting
On 6/02/2016 9:39 PM, Peter Firmstone wrote:
Hmm, thought the new parallel lock stategy in ClassLoader wasn't
deadlock prone? Guess I was wrong.
The deadlock is introduced by a custom security manager. SM's play a
critical role in many parts of the core libraries so if they utilize
synchroni
Hmm, thought the new parallel lock stategy in ClassLoader wasn't
deadlock prone? Guess I was wrong.
Observation: On an unrelated occassion, I had a URLClassLoader
synchronization hotspot (well not standard URLClassLoader, but a high
performance RFC3986 URL ClassLoader, that use normalized RF
