I am new to Openjdk and mlvm, but I have decades of experience in benchmark
cheating and hackery.
(No, that is not what I am bringing to OpenJDK.)
I went to look at Caliper, and in the tutorial, I saw this:
return dummy; // framework ignores this, but it has served its purpose!
This is no
On 2012-10-16, at 5:14 AM, Remi Forax wrote:
> Frozen/locked is a runtime property, not a type property so it's harder
> that that.
> You have to do a frozen check at the beginning of the method and pray
> that people
> will only use it with frozen object and not a not frozen one because in
>
On 2012-10-16, at 8:53 PM, Charles Oliver Nutter wrote:
>
> So *almost* everything is inlining, but one path (I believe it's the
> failure path from GWT after talking with Christian) is not reached.
> Because Hotspot's EA can't do partial EA, any unfollowed paths that
> would receive the allocat
On 2012-10-17, at 2:12 PM, Remi Forax wrote:
>> But we can't rely on this, hence it is not a true type property. But we
>> could make it be as-if.
>> I think I have to assume some sort of a marker class ("implements
>> PermanentlyLockable").
>
> A bit in the class header (equivalent to implem
Note: I did go back through the archives for a few months to see if I had
missed some earlier discussion of this. Is there an even earlier discussion
that I missed?
On 2012-10-18, at 3:21 AM, Remi Forax wrote:
> You can't forget backward compatibility. In Java 9, a program that was
> written
On 2012-10-18, at 6:36 PM, Remi Forax wrote:
>> Offhand, I don't know of any library code that manipulates Integers as
>> Integers and makes any sort of promises about their reference identity,
>> except for the nonsense about small-value interns (which we probably
>> replicate, because it is
On 2013-07-09, at 2:12 AM, Charles Oliver Nutter wrote:
> We advise our users to pass in a classloader. Class.forName's
> stack-based discovery of classloaders is too magic anyway.
It has long seemed like a bit of a crock that classloaders were not part of the
class name. Some of the squirrel
new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
Same small changes to the sources, plus a test.
bug: wrong exception was thrown in call of methodhandle to private method
fix: detect special case of IllegalAccessException, convert to
IllegalAccessError
testing:
verif
New webrev, commented line removed:
http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
On 2013-09-12, at 1:53 PM, David Chase wrote:
> I believe it produced extraneous output -- it was not clear to me that it was
> either necessary or useful to fully describe all the converted exce
, Christian Thalinger
wrote:
> + // err.initCause(ex);
>
> Why is this commented?
>
> -- Chris
>
> On Sep 6, 2013, at 4:59 PM, David Chase wrote:
>
>> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
>> Same small
substitute the borked bytecodes
necessary to get
the error, so it is not only shell-free, it can also be run outside jtreg.
On 2013-09-12, at 2:34 PM, Christian Thalinger
wrote:
>
> On Sep 12, 2013, at 11:28 AM, David Chase wrote:
>
>> New webrev, commented line r
; causes that the JVM may include.
>
> Thanks for untangling this!
>
> — John
>
> On Sep 12, 2013, at 12:17 PM, David Chase wrote:
>
>> The test is adapted from the test in the bug report.
>> The headline on the bug report is wrong -- because it uses reflection
I am not sure, but it seemed like "something" bad floated into jdk8 for a
little while, and then floated back out again.
I haven't kept close enough track of the gc-dev mailing list, but for a few
days I was frequently running out of memory when I had not been before (i.e.,
doing a build, or sim
-referencing methodhandle,
but did not test it because there's no syntax for these in Java, nor is their
creation
well-documented.
David
On 2013-09-13, at 12:02 AM, John Rose wrote:
> On Sep 12, 2013, at 5:44 PM, David Chase wrote:
>
>> Do these sibling bugs have numbers?
>
>
http://cr.openjdk.java.net/~drchase/8022701/webrev.06/
Changes made, incorporating Rose and Forax comments.
Anyone care to push this for me?
/**
+ * Use best possible cause for err.initCause(), substituting the
+ * cause for err itself if the cause has the same (or better) type.
+
bug: https://bugs.openjdk.java.net/browse/JDK-8022718
webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.00/
Problem: Needed implementation for change to the spec for JVM behavior (from
the bug report):
> JSR 335 spec, chapter "15.28.2 Run-time Evaluation of Method References"
> conta
How about this one?
http://cr.openjdk.java.net/~drchase/8022718/webrev.01/
This version tests both versions of the modifiers for "public" --
ref.getModifiers apparently sets public in some cases where the other one does
not.
Not 100% sure what those cases are, I suspect arrays from the cryptic
Further revised after consulting with John Rose on details of fix:
webrev: http://cr.openjdk.java.net/~drchase/8022718/webrev.02/
tests:
jtreg of jdk/lambda java/lang/invoke java/util/stream
defmeth (a/b testing)
jprt in progress (assuming I got the incantation right)
David
signature.asc
De
webrev: http://cr.openjdk.java.net/~drchase/8026818/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8026818
problem:
The report describes a number of problems, cause by 3 separate bugs.
The first is a dupe of https://bugs.openjdk.java.net/browse/JDK-8016839 .
The second is a fault in
On 2014-01-15, at 10:31 AM, Vladimir Ivanov
wrote:
> The fix is targeted for 8. Will be also integrated into 9.
>
> Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist,
> nashorn, jruby.
Vladimir,
Did you test also on defmeth, or has that been incorporated into one of the
20 matches
Mail list logo
