<headius[m]>
I was looking at reducing stack depth and it seems like using LambdaMetaFactory helps that and may be faster for invocation
<headius[m]>
I was looking at reducing stack depth and it seems like using LambdaMetaFactory helps that and may be faster for invocation
<headius[m]>
I was looking at reducing stack depth and it seems like using LambdaMetaFactory helps that and may be faster for invocation
<enebo[m]>
so it ends up being larger at first but as it warms it kills them off and we can have deep stacks after that
<enebo[m]>
so it ends up being larger at first but as it warms it kills them off and we can have deep stacks after that
<enebo[m]>
so it ends up being larger at first but as it warms it kills them off and we can have deep stacks after that
<enebo[m]>
the perf thing I was unaware of
<enebo[m]>
the perf thing I was unaware of
<enebo[m]>
the perf thing I was unaware of
<headius[m]>
calling handles blindly may not ever optimize well enough so when we can't bind them with indy we may want to bind to an interface
<headius[m]>
calling handles blindly may not ever optimize well enough so when we can't bind them with indy we may want to bind to an interface
<headius[m]>
calling handles blindly may not ever optimize well enough so when we can't bind them with indy we may want to bind to an interface
<enebo[m]>
dark matter
<enebo[m]>
dark matter
<enebo[m]>
dark matter
<headius[m]>
that at least gives JVM a real class to inline the LambdaForms back to
<headius[m]>
that at least gives JVM a real class to inline the LambdaForms back to
<headius[m]>
that at least gives JVM a real class to inline the LambdaForms back to
<enebo[m]>
I almost have this **{} thing fixed. I am just debugging the new IR
<enebo[m]>
I almost have this **{} thing fixed. I am just debugging the new IR
<enebo[m]>
I almost have this **{} thing fixed. I am just debugging the new IR
<enebo[m]>
headius: Do you think that will change warmup?
<enebo[m]>
headius: Do you think that will change warmup?
<enebo[m]>
headius: Do you think that will change warmup?
<headius[m]>
I do not know... it is another call into Lambda guts but it may be a net gain avoiding the LambdaForm tree
<headius[m]>
I do not know... it is another call into Lambda guts but it may be a net gain avoiding the LambdaForm tree
<headius[m]>
I do not know... it is another call into Lambda guts but it may be a net gain avoiding the LambdaForm tree
<enebo[m]>
perhaps it solves that as well
<enebo[m]>
perhaps it solves that as well
<enebo[m]>
perhaps it solves that as well
<headius[m]>
dunno how valuable this is... perf wise indy will always be best and startup wise everyone will use --dev
<headius[m]>
dunno how valuable this is... perf wise indy will always be best and startup wise everyone will use --dev
<headius[m]>
dunno how valuable this is... perf wise indy will always be best and startup wise everyone will use --dev
<headius[m]>
getting indy to have no added cost would probably be a better use of time
<headius[m]>
getting indy to have no added cost would probably be a better use of time
<headius[m]>
getting indy to have no added cost would probably be a better use of time
<enebo[m]>
indy always on is a great goal but we are on dual track right now where some people can enable fully. A little more perf is not a bad thing. If it happens to improve warmup then that also would make it closer to being always on
<enebo[m]>
indy always on is a great goal but we are on dual track right now where some people can enable fully. A little more perf is not a bad thing. If it happens to improve warmup then that also would make it closer to being always on
<enebo[m]>
indy always on is a great goal but we are on dual track right now where some people can enable fully. A little more perf is not a bad thing. If it happens to improve warmup then that also would make it closer to being always on
<headius[m]>
have you been able to do any verification of the release artifacts after my gem change?
<headius[m]>
have you been able to do any verification of the release artifacts after my gem change?
<headius[m]>
have you been able to do any verification of the release artifacts after my gem change?
<headius[m]>
it looked good to me diffing the files
<headius[m]>
it looked good to me diffing the files
<headius[m]>
it looked good to me diffing the files
<enebo[m]>
I thought I would be done with the **kw thing but I am getting closer
<enebo[m]>
I thought I would be done with the **kw thing but I am getting closer
<enebo[m]>
I thought I would be done with the **kw thing but I am getting closer
<enebo[m]>
At this point if you can compare to .16 and see the proper diff I doubt we will see any issues
<enebo[m]>
At this point if you can compare to .16 and see the proper diff I doubt we will see any issues
<enebo[m]>
At this point if you can compare to .16 and see the proper diff I doubt we will see any issues
subbu|lunch is now known as subbu
subbu|lunch is now known as subbu
subbu|lunch is now known as subbu
ur5us has joined #jruby
ur5us has joined #jruby
ur5us has joined #jruby
<headius[m]>
enebo: this is not directly related to 9.2.17 but might go a long way toward helping jruby-complete users on Windows avoid leaking jffi DLLs: https://github.com/jnr/jffi/pull/99
<headius[m]>
enebo: this is not directly related to 9.2.17 but might go a long way toward helping jruby-complete users on Windows avoid leaking jffi DLLs: https://github.com/jnr/jffi/pull/99
<headius[m]>
enebo: this is not directly related to 9.2.17 but might go a long way toward helping jruby-complete users on Windows avoid leaking jffi DLLs: https://github.com/jnr/jffi/pull/99
<headius[m]>
basically adds a property jffi.extract.name that uses a specific filename instead of a temp name, and reuses any existing file at that location
<headius[m]>
basically adds a property jffi.extract.name that uses a specific filename instead of a temp name, and reuses any existing file at that location
<headius[m]>
basically adds a property jffi.extract.name that uses a specific filename instead of a temp name, and reuses any existing file at that location
<headius[m]>
I do not have any way to verify that the already-extracted file and the shipped one are the same so that is buyer beware
<headius[m]>
I do not have any way to verify that the already-extracted file and the shipped one are the same so that is buyer beware
<headius[m]>
I do not have any way to verify that the already-extracted file and the shipped one are the same so that is buyer beware
<headius[m]>
the other two unresolved for 9.2.17.0 is the new launcher .exe and psych, which can get punted (user can install new if they really need the error fix)
<headius[m]>
the other two unresolved for 9.2.17.0 is the new launcher .exe and psych, which can get punted (user can install new if they really need the error fix)
<headius[m]>
the other two unresolved for 9.2.17.0 is the new launcher .exe and psych, which can get punted (user can install new if they really need the error fix)