I think I got it!
MethodHandle result = MethodHandles.catchException(foo,
postException); # handles exceptional path of finally and throws
result = MethodHandles.foldArgments(postCall, result); # handles
non-exceptional path of finally.
Am I right?!
On Fri, Jun 10, 2011 at 7:12 PM, Charles Olive
I just posted your trick (a "duh" moment for me) to JVM-L, along with
an explanation of why it doesn't solve the try/finally problem. The
exceptional and non-exceptional paths need to be exclusive to match
what try/finally does.
- Charlie
On Fri, Jun 10, 2011 at 7:05 PM, Charles Oliver Nutter
wr
On Fri, Jun 10, 2011 at 6:55 PM, John Rose wrote:
> On Jun 10, 2011, at 4:39 PM, Charles Oliver Nutter wrote:
>
>> Please tell me I'm wrong, or tell me that we can modify catchException
>> in some way to also allow post-processing of non-exceptional results
>> (with return value inserted where the
On Jun 10, 2011, at 4:39 PM, Charles Oliver Nutter wrote:
> Please tell me I'm wrong, or tell me that we can modify catchException
> in some way to also allow post-processing of non-exceptional results
> (with return value inserted where the Throwable would go)!
I think this does what you want:
Please, please have a look at my recent threads on JVM-L. I am worried
I've found a major hole in what MethodHandles can do. Specifically,
there's no way to post-process a given handle, receiving both its
arguments and its return value and deciding what to do, for something
like this try/finally fo
On Jun 10, 2011, at 3:37 PM, Charles Oliver Nutter wrote:
> On Fri, Jun 10, 2011 at 5:32 PM, Christian Thalinger
> wrote:
>> It inlines fine with the latest HotSpot and JDK7 b145. I think we're good
>> :-)
>
> Sorry, the logic for this never actually landed on JRuby master, and I
> lost the com
On Fri, Jun 10, 2011 at 5:32 PM, Christian Thalinger
wrote:
> It inlines fine with the latest HotSpot and JDK7 b145. I think we're good :-)
Sorry, the logic for this never actually landed on JRuby master, and I
lost the commit somehow...so the inlining you're seeing is the old
logic with a custo
On Jun 5, 2011, at 7:23 AM, Charles Oliver Nutter wrote:
> OH, and FWIW, here's the LogCompilation -i output roughly around where
> I'd expect to see op_plus and op_lt inlining:
>
>@ 27 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>@ 27 java.lang.invoke.MethodHandle::invokeExact (1
On Jun 5, 2011, at 7:23 AM, Charles Oliver Nutter wrote:
> OH, and FWIW, here's the LogCompilation -i output roughly around where
> I'd expect to see op_plus and op_lt inlining:
>
>@ 27 java.lang.invoke.MethodHandle::invokeExact (0 bytes)
>@ 27 java.lang.invoke.MethodHandle::invokeExact (1
On Jun 4, 2011, at 5:19 AM, Ola Bini wrote:
> On 2011-06-04 01.47, John Rose wrote:
>> On Jun 3, 2011, at 7:07 AM, Ola Bini wrote:
>>
>>> Is there anything I can do to help out with finding this problem?
>>
>> I can't reproduce the VM crash yet. Like Christian, I got through
>> problems 1 and 2,
I found a regression between Mac OS X MLVM build from April 4 and June 6 (based
on bsd-port jdk7-b145). Here's a minimal reproducing testcase:
public class TestVarArgInvoke {
public static void main(String[] args) throws Throwable {
java.lang.invoke.MethodHandles.publicLookup().unreflect(
I had a good version of JDK and ASM, but only the to-be-rewritten class was
compiled under Eclipse using it's compiler.
Is't it a bug that ASM allowed it's output class to have tag 15 constant in
it while the version of class file like it was before class maipulation. I
thought that if ASM takes c
On May 27, 2011, at 12:35 AM, Ola Bini wrote:
> On 2011-05-27 12.58, John Rose wrote:
>> On May 27, 2011, at 12:24 AM, Ola Bini wrote:
>>
>>> But then it crashes at the same place.
>>
>> Excellent!
>>
>> So this works in b144 but not in mlvm?
> Yes, that's correct.
Is there any other crash you
13 matches
Mail list logo
