Hi, Off-list as i am not sure i wanna commit to this publicly :-)
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 >
