M3 stabilization requests for 2009/4/30

Phil Race Phil.Race at Sun.COM
Thu Apr 30 15:35:56 PDT 2009



Vita Santrucek wrote:
> ->  6762511  anthony.petrov   Translucency is not working on Linux using
> ->                            Metacity
> 
> Already present in 6u14 for the past 4 weeks, no regressions found so far. 
> I'd be OK to let this one i

I agree. Its in 6u14 as of b04 so I think we can allow it here.

> 
> ->  6794764  artem.ananiev    Translucent windows are completely repainted
> ->                            on every paint event, on Windows
> 
> Webrev's not there, but doesn't sound like simple fix. I'd prefer to get 
> this in one in M4.

I see the webrev : http://sa.sfbay.sun.com/projects/awt_data/7/6794764/

I agree, this is a performance fix that so far as I can tell isn't critical
to M3 and touches sensitive areas like the Swing repaint manager.

> 
> ->  6812298  anthony.petrov   Dynamic GraphicsConfig changes don't work on
> ->                            X11 platforms
> 
> Phil, if you consider this one super safe and unlikely to cause 
> regressions I'd take it in, Marina is the Linux/OpenSolaris release and 
> these bugs seem to significantly impact these platforms.
> 

I don't know if I go so far as to call it super-safe.

> If we could get it in b58 it would be better.

Too late for b58. I guess this is a no unless there's a better
justification for the risk and more explanation of the impact.

> 
> ->These first three are nontrivial changes, and none seems critical for M3.
> ->Phil, Vita -- what say you?
> ->
> ->  6834177  vladimir.kozlov  Running jsynprog on Solaris Nevada can cause
> ->                            JVM crash
> 
> 
> Agreed, we'll have the initial OpenSolaris release on Sparc in early June. 
> I rather makes me wonder if we wouldn't want this fix in 6u14 also.
> 
> 

OK from me.

> ->VM crash on 64-bit sparc.  The fix isn't trivial but it's smaller than
> ->it looks, and VM crashes are bad.  I'm leaning toward accepting it.
> ->Paul? Vita?
> ->
> ->  6834246  alan.bateman     (ch) AsynchronousSocketChannel#write
> ->                            completes with wrong number of bytes written
> ->                            under load (win)
> ->
> ->Not critical for M3 but the fix is limited to the Windows asynchronous
> ->socket-channel code, so if it's wrong then that's the only thing that
> ->would break.  I'd say "yes" to this one.
> 

OK from me.

-phil.

> 
> GO.
> 
> Vita
> 
> 
> ->
> ->- Mark
> ->



More information about the jdk7-rt mailing list