6804523: Tuple Signatures

[Michael Barker]

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
<headius at 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 <mikeb01 at 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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>