Cheers for the vote of confidence! I've just won a small skirmish with the verifier and I seem to have anonymous tuples on method calls working. Just putting some more tests together before I send in a patch.
Mike. On Sun, May 15, 2011 at 6:39 PM, Charles Oliver Nutter <head...@headius.com> wrote: > Very cool! I am glad someone with the requisite skills has begun looking into > John's tuples post! > > I am not an expert on Hotspot internals, so I am afraid I can't respond to > your query. But we (JRuby and other dynlangs) most definitely have a need for > tuples in representing complex numeric boxes like JRuby's Fixnum and Float > (which aggregate a 64-bit long or double and other metadata associated with > Ruby objects) in order to make math operations that consume or produce those > values cheap and fast (by avoiding the allocation cost as often as possible). > > Hopefully once you have signed the contributor agreement you will be able to > use the MLVM patch repo to host your project. I am excited to see this happen! > > - Charlie (mobile) > > On May 15, 2011, at 3:35, Michael Barker <mike...@gmail.com> wrote: > >> Hi, >> >> I've been following the MLVM list for a while now and I would like to >> get involved. I'm interested in tuple signatures >> (http://blogs.oracle.com/jrose/entry/tuples_in_the_vm). I'm fairly new >> to the hotspot code base, so you may have to forgive my lack of >> knowledge. >> >> I've spent a couple of weeks looking through the hotspot code and a >> couple of days hacking away in classFileParser.cpp & signature.cpp and >> I managed (with a lot of nastiness) to get a class file with a method >> signature containing anonymous tuple to load. >> >> My biggest question is, where should the erasure of the tuple >> signature be handled? There seems to be a couple of approaches that >> would work. The one I'm leaning toward it having most of the logic >> implemented in the SignatureIterator (and friends inside >> signature.{cpp,hpp}) and only storing the un-erased signature in the >> constant pool. Those parts that care about the full signature e.g. >> LinkVerifier can just use the UTF-8 string as normal, the parts that >> care about the detail of the signature, e.g. argument counts/size can >> just walk it using an iterator. >> >> The other possibility would be to construct a second entry in the >> constant pool with the erased signature and have the methodOopDesc be >> able to return either, leaving the SignatureIterator unchanged. This >> feels more brittle as it would be very easy accidentally pass the >> wrong one to the SignatureIterator or simply not have enough >> information to know which version was required in a given context. >> >> Regards, >> Mike. >> >> P.S. I haven't signed the contributor agreement yet, I'll send that >> off on Monday once I'm near a printer. >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
