Re: IntelliJ debugger?

2015-04-02 Thread Dain Sundstrom
So I did a bunch more testing, and this is what I found: - The IntelliJ debugger ignores the “source” declaration in the class file and instead always looks for a “.java” file in the source path - The file must contain a java class declaration with the same name - The file must be “recognized” by

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread John Rose
On Apr 2, 2015, at 3:08 PM, Vladimir Ivanov wrote: > > Member access permission check isn't performed if caller and member owner > class are loaded by the same class loader (which is the case with > CallSite$DependencyContext and CallSite classes). Heh! And I thought I had compiled the refle

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread Vladimir Ivanov
John, Thanks for the clarification! BTW why do you think security manager was the problem? (1) Class.getDeclaredField() is caller-sensitive; and (2) DependencyContext was eagerly initialized with CallSite (see UNSAFE.ensureClassInitialized() in original version). CallSite$DependencyContext an

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread John Rose
On Apr 2, 2015, at 9:17 AM, Vladimir Ivanov wrote: > >> >> I recommend putting CONTEXT_OFFSET into CallSite, not the nested class. >> For one thing, your getDeclaredField call will fail (I think) with a >> security manager installed. >> You can load it up where TARGET_OFFSET is initialized. >

Re: Lambda in security manager initialization fail

2015-04-02 Thread Vladimir Ivanov
Peter, Thanks for the exhaustive analysis. Filed JDK-8076596 [1] Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8076596 On 3/30/15 11:01 PM, Peter Levart wrote: Hi Max, On 03/30/2015 05:24 PM, Wang Weijun wrote: I have a customized security manager: import jav

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread Vladimir Ivanov
Aleksey, thanks a lot for the performance evaluation of the fix! Best regards, Vladimir Ivanov On 4/2/15 7:10 PM, Aleksey Shipilev wrote: On 04/01/2015 11:56 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/ http://cr.openjdk.java.net/~vlivanov/8057967/

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread Vladimir Ivanov
John, Peter, Thanks a lot for the feedback! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/hotspot/ http://cr.openjdk.java.net/~vlivanov/8057967/webrev.01/jdk/ Question: How common is state 2 (context-free CS) compared to state 3 (indy-bound CS)? It's quite rare

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread Aleksey Shipilev
On 04/01/2015 11:56 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/ > http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/ > https://bugs.openjdk.java.net/browse/JDK-8057967 Glad to see this finally addressed, thanks! I did not look through the

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

2015-04-02 Thread Peter Levart
Hi Vladimir, Would it be possible for CallSite.context to hold the Cleaner instance itself (without indirection through DependencyContext)? DEFAULT_CONTEXT would then be a Cleaner instance that references some "default" Class object (for example DefaultContext.class that serves no other purp