> On 11 Jul 2017, at 16:34, Paul Sandoz <paul.san...@oracle.com> wrote: > > Hi, > > Off-list as i am not sure i wanna commit to this publicly :-) >
Sigh, email fail, looks like i just have :-) Paul. > In the interest of moving this forward independent of MVT i can prototype > some of this if you like and use the three usages of U.DAC in the JDK as > use-cases (see also [1]) Perhaps surprisingly grepcode.com reports no > external usages of U.DAC. > > Some use-cases for U.DAC could be replaced by an isolated method feature, > which makes me wonder if that is really the actual public feature we really > want rather than anon/nameless classes? > > My gut feeling is 2) can be implemented straightforwardly on top of > Unsafe.DAC with appropriate checks, if we are ok with the current HS > implementation at least as a starting point. To me the tricky bit is the spec > gymnastics, it would have to be subset of the eventual behaviour and that can > only expand in scope with refinement of terms. Is that a reasonably accurate > assessment? > > I believe we can also prototype the constant pool patching in an indirect > manner as indicated by John and Remi. > > That leaves the more general nested named class support which requires more > fundamental hotspot work. > > So in terms of progress order it could be: 2), 3), 1). But if we throw > isolated methods into the mix then the plot thickens. > > Paul. > > [1] > https://bugs.openjdk.java.net/browse/JDK-8078602 > Support j.l.i.BoundMethodHandle$Species_* classes unloading > https://bugs.openjdk.java.net/browse/JDK-8168848 > Too many anonymous classes that aren't unloaded > > >> On 11 Jul 2017, at 14:42, Karen Kinnear <karen.kinn...@oracle.com> wrote: >> >> Paul, >> >> We are working hard on getting the nest mates requirements clarified. >> I would like to use that to support the Lookup.defineClass and not do a >> Quick&Dirty >> in advance for MVT . I think we should stick with the reduced restrictions >> for withfield for early access. I think we should put our energy into getting >> nest mates and Lookup.defineClass ready. >> >> We have three parts to Lookup.defineClass. >> 1) PRIVATE mode handling - which we believe we can support with nest mates >> - we do not want to do any versions of this based on unsafe.DAC current >> behavior, >> - we are looking at cleaner behavior for nestmates >> 2) “temporary” name - i.e. find doesn’t work >> 3) CP patching/user data >> >> My mental model is that we don’t have to add all of these at the same time, >> although we will want user feedback on when to remove >> unsafe.DefineAnonymousClass. >> In fact, we would love more examples of current use cases, to help guide our >> design. >> >> thanks, >> Karen >> >>> On Jul 5, 2017, at 2:43 PM, John Rose <john.r.r...@oracle.com> wrote: >>> >>> On Jul 5, 2017, at 11:39 AM, Paul Sandoz <paul.san...@oracle.com> wrote: >>>> >>>> >>>> I was unsure if we require a new method L.defineAnonClass or could >>>> leverage the existing L.defineClass. IIUC for expediency the current hooks >>>> in the VM lean towards anon classes, since there is already code to defer >>>> to the host class, whereas the general defineClass case will likely >>>> require more work, although i can potentially see some short cuts if we >>>> focus on VCC/DVT. >>>> >>> >>> Good point. Yes, that part isn't designed yet. It may manifest as an >>> extra argument or two to the L.dC. >>> >>> At least two degrees of freedom apply there: 1. suppressing the name (no >>> system dictionary update), >>> 2. providing some sort of "user data" to bind to the class (can be a single >>> ref., replaces CP patching). >>> >>> For MVT we can just generate a throwaway name, like DVT.getName()+":29348". >>> >>> — John >> >
